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

["Dan Kaminsky" <effugas best com>]

-----Original Message-----
From: sun <as387@yfn.ysu.edu>
To: Dan Kaminsky <effugas@best.com>; gnome-gui-list@gnome.org
<gnome-gui-list@gnome.org>
Date: Saturday, July 25, 1998 6:51 PM
Subject: Re: To answer your question about the upcoming Style-Guide...


>Dan Kaminsky wrote:
>
>> >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
>>:-)
>
>i, for one, stand with george in that i think the icon size is perfect
>for my desktop.


They're significantly too large for mine.  Both you and George have your
preferences, and that's fair, but 24x24 is a much better size than 48x48
as-is for at least a sizable minority of the computer population.

>i'll concede again, however, in that this should be a little more
>flexible: i'm looking forward to running gnome on my palm-pilot, and i
>think the panel should be no wider than about sixteen pixels on that...
>just wide enough to contain recognizable icons. :)


Honestly, the gnome bar, and *maybe* every window should shrink and zoom
according to some user controllable preference.

>(to the ever-present level-headed non-dreamers who would propose that
>i'm getting a little carried away with this thing, let me ask, "why
>not?")


Heh ;-)

>> >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...
>
>i can't possibly overstate my disagreement with this sentence. you
>yourself have been arguing against "clutter;" i should hardly have to
>point out that auto-hiding (or even explicitly hiding) the panel is the
>_best_ compromise between your clutter-free desktop and my
>multiple-entry-points-plus-status-applet do-all desktop headquarters.


Well, the thing is that a hiding panel is *only* really useful for static
windows.  Think about it--if you have new mail, you don't want that fact
hiding on the panel sunken underscreen!  Same with the stderr box, and
anything else that announces *to* the user.

>in fact, george, can i put in a feature request for a panel that
>auto-hides even when drawers with applets are open? perhaps even a
>choice in the individual drawers' preference window to keep drawers open
>even when the panel is hidden (automatically and explicitly)? :)


One thing that's absolutely critical if panel hiding suggestions are to be
implemented:  One must have to move past a critical point to unhide a panel,
and that critical point CAN NOT at ALL precede what appears to be the
controls for another window.  For example:

Suppose we're dealing with a horizontal panel.  Along the Y access, the
bottom five or ten pixels must ONLY possess a visual clue to click to invite
panel.  if you click down here, it doesn't matter if half the screen gets
taken over by a panel; this is what the user wants.  Contrast this with the
way the Microsoft Office Quicklaunch UI works, which is to take ANY area
that *would* be occluded by an underlying app(half the screen occluded?  oh
well)  and bring up the occluder if the mouse strays into this "dead zone".

I can't tell you how many times I just wanted to scroll down in Netscape and
was given the Office Quicklauncher.