Re: Problems, Ideas, Other

[bob cs csoft net]

On Thu, 26 Aug 1999, Elliot Lee wrote:

> On Thu, 26 Aug 1999 bob@cs.csoft.net wrote:
> 
> > > It's not just a "little fixing up". It needs a total rewrite.
> > 
> > Hmm... Maby so. But some standard needs to be established. Many programs
> > are being changed from /dev/dsp to esd. It would be ugly to have to change
> > them yet again to another protocol.
> 
> We have been planning to have a libesd wrapper that allows programs to use
> the legacy API to access the new sound server without recompiling.

Good.
Dont plan yet another switch in the next 10 years thow. It might annoy
people. 
"CIV CTP" was a dsp program, then an esd one...
It might really bother Loci to have to rewrite it again. :)

> 
> > Request: whatever we change to, it would be very good to maintain the
> > network streaming ability.
> 
> Of course!
> 
> > > The alarm applet is primarily GUI, and while it could be implemented in
> > > terms of cron, it would be more difficult to do this than just
> > > reimplementing the needed functionality inside the alarm applet.
> > 
> > I stand corrected. Maby there needs to be a gnome to cron bridge of some
> > kind. It might be better off being a transparent program then an applet...
> > (not everyone uses the panel.)
> > 
> > Seen cromagnon? It provides a gui front end to cron. 
> 
> Yes, that was one of the original five or so GNOME apps, but it hasn't
> been maintained since then.
> 
> Having a GNOME front-end to edit crontab would be nice. (Maybe cromagnon
> just needs a maintainer.)

I talked to the maintainer and it sounds like it might be worked on again
soon. (I might be helping)

> 
> > > > GNOME-WM: Heven knows we dont need yet another WM. Finishing the WM
> > > > Specification should remove the need for a GNOME WM. It will save alot of
> > > > time and trouble making a GNOME WM.
> > > 
> > > Well, the main problem is that there isn't a window manager that
> > > integrates perfectly with GNOME, and the GNOME WM project intends to fix
> > > this problem one way or another. Because of KDE reluctance to use CORBA,
> > > the WM specification will not include CORBA interfaces for configuring the
> > > GNOME window manager, which GNOME really needs.
> > 
> > Why does gnome need to talk to the WM with corba for?
> 
> For WM configuration - e.g. retrieving focus settings
> 
> > I was under the impression that the WM was incharge of managing
> > windows (and desktops). There shouldnt need to be much communication
> > between the two. The communication could be done through hints and if
> > you really want, a corba wrapper to the hints.
> 
> Window hints are one-way only - the window manager can't communicate back
> to the app that way. CORBA is a nice, standardized way for programs to
> talk to each other.

How does a wm like sawmill tell the gnome pager that it has added a
desktop? Also, why does a program other then a wm configuration program
need to talk to the wm, or does it?

I think the idea you are talking about is making a standard "window
manager config" capplet. The problem with this, is the window manager is
then limited to the features implamented in the capplet. I do not see much
of a problem with the current setup. Use the capplet that comes with the
WM.

> 
> > > > All that GNOME has over KDE now is:
> > > > License (kinda)
> > > > Languages
> > > 
> > > There's more than that, it's just that perhaps you don't know all the cool
> > > stuff that is going on with gnome right now. :)
> > 
> > Enlighten me. I am sure that alot of people would like to here about it. 
> 
> gill/libart/canvas
> gnome-mailer
> bonobo
> gdk-pixbuf
> gnumeric
> 
> > Everything is important but alot of programs are going to depend on
> > the above listed stuff. So finishing them quicker then some of the
> > less important stuff would allow for better programs to be written.
> > Bonobo and GCONF are examples.
> 
> gconf replaces an existing GNOME subsystem, and Havoc doesn't seem to be
> thinking it is even a component 
> 
> > > > A note about VFS:
> > > > I still think it is a bad idea, File systems are the job of the kernel.
> > > 
> > > You'll never get the kernel people to add support for HTTP filesystems and
> > > such, because they don't belong there. (There was a userfs which
> > > implemented this, but it has gone unused.)
> > 
> > Wouldent it be easier to resurect the userfs implementation? If it is
> > already implemented, it would be a far better thing then vfs.
> 
> No, because userfs was never stable AFAIK. Also, if you use a kernel
> filesystem you are limiting yourself to the POSIX API as far as file
> access goes, which doesn't allow for extensions like metadata and
> password-access (imagine all the horrible hacks that would have to be done
> to allow programs using userfs to access password-controlled HTTP
> resources).

What about smbfs? It does support passwords. Althow, it only supports
linux. Hmm. how about a nfs server with modular plugins for protocols. VFS
like, but works with all programs. Hmm, maby a step above.
Take the libvfs library, and build a nfs server that uses it. It could be
mounted by any os, and support any filesystem libvfs does.

Question, why is metadata a good thing. One of, at least I think, the
mac's greatest problems is its way of storing metadata. It makes a file
hard to transfer. Why not just store the metadata at the end of the file
itself?

> 
> > I have been keeping an eye on gnome for a long time. If I can confuse
> > "gnome=X" then so will most people. Making a distinction between console
> > gnome and X gnome would help. Maby prefixing Gnome console stuff with
> > gnomec_ or X stuff with gnomeX_. or just making 2 parts to gnome libs.
> > libgnome and libgnomec.
> 
> We already have two parts to gnome-libs - libgnome and libgnomeui.

O. Cool. Is there any plans to separate libgnome and libgnomeui into 2
packages so that you dont need all of gnome to program a console app?
I thaught gnome was X only because it only had one lib package.
> 
> > > gnome-db is a higher-level layer on top of flat files, the ODBC API, or
> > > whatever, so applications can do their DB tasks easily.
> > 
> > I dont see the difference between gnome-db and ODBC. Why reinvent the
> > wheel?
> 
> My point was that it's not reinventing the wheel. It's a higher-level API
> than ODBC.

So what is it? Is it a fiew helper functions that make ODBC easier to
use, or is it an implamentation of ODBC?

> 
> > > > Name space issues:
> > > > People that distribute programs should only have to create ONE desktop
> > > > file that should work for all desktop environments. Having to make one for
> > > > Gnome, KDE, enlightenment, whatever is a drag. This needs to be addressed.
> > > > Also, it is a real pain to have the gnome desktop in .gnome-desktop. It is
> > > > difficult to get at from both the console and from normal gnome programs.
> > > > I recommend changing it to "desktop" or ".desktop".
> > > 
> > > Your post was in the vein of slashdot: lots of uninformed moaning and
> > > wailing, and probably discouraged people more than anything else. If you
> > > want to help GNOME along, there's lots that you can do to help, so don't
> > > feel put off about trying to make suggestions - it's just that this
> > > particular way of going about it doesn't help at all.
> > 
> > How would you suggest making suggestions and asking questions? I
> > thaught the gnome-list was for discussion. If not, point me in the
> > correct direction.
> 
> It's not what you did, it's how you did it. Hackers need encouragement,
> positive reinforcement, constructive criticism, and of course actual
> contributions. :) Your post was taken by many as being a "You guys should
> give up, KDE rules" even though you probably didn't mean it that way.

That was not my intention, and I apologize for my bad wording. I dont
think that we should give up. Looking at whats comming up on the kde side,
I got the impression that it could potentually push gnome even farther out
of the way. It is my wish that this would not happen. I was trying to
formulate ideas to help gnome stand out again.

> 
> -- Elliot
> Who me? I just wander from room to room.
> 
> 
>