Re: Random thought...




-----Original Message-----
From: JR Tipton <nails@maybe.net>
To: Dan "Effugas" Kaminsky <effugas@best.com>
Cc: gnome-gui-list@gnome.org <gnome-gui-list@gnome.org>; recipient list not
shown: <recipient list not shown:>
Date: Friday, August 14, 1998 7:39 PM
Subject: Re: Random thought...


>On Fri, 14 Aug 1998, Dan "Effugas" Kaminsky wrote:
>> GNOME needs a *STANDARD WM*.  I assume this is going to be E.  There
needs
>> to be a starting point from which other WMs can grow.  I *want* other WMs
to
>
>I'm not taking a stance here or anything, but just prodding you to
>elaborate a little bit.  I'm confused because in the GNOME manifesto it
>says:
>        Gnome defines a set of "hints" for window managers. If you use a
>Gnome aware window manager it will co-operate nicely with Gnome. If you
>don't then Gnome works just fine. The "hint" interface is published in
>full for anyone to use.
>                   No religion - pick any window manager
>
>...not that I'm saying it conflicts with what you're saying, but then
>again I am not sure what you're saying.


In a way, I'm arguing that there's going to need to be a standard
"hintreader", if you will, much like Amaya.  KDE, for all of its faults, is
a complete environment.  In fact, it is so complete that it is impossible to
extend.  That's Bad.  What I'm saying is that GNOME *will* have a standard
WM.  This isn't a question, this isn't something we can choose not to have.
Whatever ships with Redhat 6 is going to be the standard.

That being said, other WMs must be able to, in a simple manner, take
advantage of the functionality that GNOME provides and provide the
functionality that GNOME requests.  This is what "hints" are about.

Now, it's quite possible that there are some out there who believe GNOME
shouldn't be any standard, that it should refer only to the applications
themselves, not their shell.  I don't buy this.  GNOME is an environment.
Drawing artifical boundries in the environment is foolhardy and eventually
self-defeating--we will lose to KDE and Windows, without a doubt.  A
consistent gestalt, with components being extendable or even removable, is
necessary.

To explain in more concrete terms, consider the minbar.  I am advocating the
minbar as a taskbar type item to be placed upon the panel, and possibly
through other areas.  A GNOME-Compliant WM, in my opinion, should be able to
incorporate the minbar in a unified panel interface.  That would mean that,
no, we wouldn't have an app that just works with the afterstep dock, or the
windowmaker wharf, or whatever.  Perhaps bleeding edge functionality might
be wharf/dock specific, but in general, we should see all "docking apps"
dock to the same "panel".

A further explanation, probably better:  GNOME is going to specify a style
for applications to install themselves.  GNOME Compliant WM's should be able
to read the "installed applications" menus and import them into themselves,
instead of requiring constant resynchronization.  If you think about it,
this is far better way of encouraging diversity of window managers--every
time you change WMs, the common segments follow you.  Yet another separation
of content and presentation!

I do not want GNOME to be a bad thing for WMs, but we have three choices.
Either GNOME becomes a standard but extensible windowing system(what I
want), or a standard and inextensible windowing system(KDE), or it fails.
It's That Simple.

>> support GNOME, but they need to do it in a manner that extends, not
>> replaces.  Docks, wharfs, panels, these are the fruits of redundancy.  I
>> don't want to see "only works with Gnomemaker" or "only supported by
>
>See, I'm confused here.  Why do you say the wm "needs" to do anything?  It
>says in the GNOME Manifesto that it doesn't.  Again, I hope you can afford
>the time to elaborate a bit :)


OK, we're poking at the WMs a little.  They really really ought to accept
the hints that say "you have an application here that wants to sit in your
dock, please manage it".  Fine, GC2 instead of GC1, but really...


>Thanks.
>
>william r. tipton
>
>



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]