Re: To answer your question about the upcoming Style-Guide...

-----Original Message-----
From: George <>
To: <>
Date: Friday, July 24, 1998 2:59 AM
Subject: Re: To answer your question about the upcoming Style-Guide...

>On Fri, Jul 24, 1998 at 01:55:03AM -0700, Dan Kaminsky wrote:
>> What I'm talking about is *default behavior*.  I *rail* on Windows
>> default behavior requests that apps install into author subheadings
>> of app category subheadings.  That, and the Programs section has no
>I don't see the point of this arguemtn ... nobody is saying otherwise ...
>and this is the way it IS
>have you even looked at gnome?

Yeah, this is one of the dumber arguments I've been in.  I defended
Microsoft at one point in that long post, so I bashed them in another.  Next
thing I know I'm being asked to describe how GNOME should be...suddenly
people thing I'm arguing that GNOME should be changed in this respect...

>> BY DEFAULT, apps should not install directly onto the toolbar, nor should
>> they install into categories enclosed on the toolbar.  The default
>> should be the one the designers believe is the most efficient.  If the
>> has a specific case, the *user* should choose to move the app to the
>> Gnomeprint.
>that's what it is ... default is to put a .desktop files somewhere in the
>system apps/ menu ...
>the app shouldn't try to add it directly to a panel anyway .. since it
>know the panel setup ... the setup doesn't have to be a single bar at the
>bottom .. it can be a wharf like corner widget on the top right .... and
>for all it knows panel 0 could be some obscure drawer somewhere

Applications need to automatically add themselves to something.  As for
where, I'm arguing that there be a standard set of categories(there are
already, aren't there?) as well as maybe a standard set of subcategories.
Stuff would try to go into its own home.

>the gnome panel is not a single bar panel ... that's just the way it starts

>up at first .. and that's the way most people like it as it seems

Can the Gnome panel be dual bar on a single side?

>> Actually, I think the Gnomeprint and the app loaders right now are *far*
>> large.  The only reason right now I see for objects of this size is the
>> Stealth Project that I just got the screen shots to complete...
>the reason they are large is "the icon wants to be readable" .. and the
>important reason is that gnome panel is not just a launcher .. it can also
>host applets ... and most applets require more space ...

Ah.  Gnome panel's gotta become a wee bit more forgiving...

>plus if they were any smaller they would be hard to hit with the mouse ...

Uh?  You kidding?  If they were any bigger they'd be hard to miss.  :-)
Seriously, small icons in Win32 are 16x16 pixels and they're completely
clickable.  It's not hard to select lines of text, and they're about this
size if not smaller.  Almost everything you've said is valid, but not this

>that's why there are all those ways to hide the panels out of the way

Hurm.  I think the need to hide something shows a flaw in design...

>> The big question is, since *any* object along a side is going to make it
>> more difficult to utilize the rest of that side, assuming you use a
>> side for all information that should constantly be on screen...what
>> information gets through?
>> What indeed...
>ummm .. I don't really know what you mean here ... if I have a corner
>applet on the top .. I can still use the rest of that side for extra space
>for smaller windows ... it would only be "wasted" had I used only one
>app at a time, maximized over the screen .. and even then ... I can just
>put the app over the panel ...

Bleagh.  If I'm gonna go to all the trouble of having a panel set up, it
should remain topped.  Not to mention, finding smaller windows to really fit
in there doesn't work wonderfully.  You just end up with tons of overlaps,
which GUIs really need to start learning how to gracefully eliminate.

>> You misunderstand.  GNOME is quite powerful, and lets say suddenly you go
>> ahead and do something that leaves you with no ability to do anything
>> you understand the CLI and .rc files.  You need something like, say
>> Control-Alt-F12 to return to default.  Something like that(I don't really
>> like some random key config, cuz it's documentation-dependant).
>this is what session managment does ... no need for a keybinding ... just
>start up a default session from gdm (or whatever the name will be)
>or start up a different one you saved ...
>though the apps aren't session specific, the system menu can't be changed
>by a user anyhow ... so a user can always build his user menu any way he

Whatever it is needs to be simple enough for the newbie to save him or
herself without using the CLI.

>> I see Redhat and GNOME becoming like Netscape with Mozilla.  Support,
>> direct, contribute, and take the finished product and spread it
>> the marketplace.  If you don't think GNOME is going to have a standard
>> you're kidding yourself.  Whatever comes in Redhat 5.2 or 6.0 is going to
>> the standard GNOME WM.  The E guy *is* working for Redhat.  What's
>> is UNLIKE KDE, Gnome apps will run under any WM.  That's pretty critical.
>you seem to be forgetting that redhat is not the only distribution out
>there ... plus they did have this habit of putting more windowmanagers
>in there anyhow ... so it's not like they will use one
>and I really really doubt redhat would be as naive as to include E as the
>default WM ... most likely the default in redhat will still be
>fvwm2 and afterstep

Haven't both Redhat and Debian committed to making Gnome the standard UI?

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