On Sun, Mar 26, 2000 at 09:22:27PM +0000, Seth Burgess <sjburges@xxxxxxxx> wrote:
> > The truth is: any window may or may not fit any screen size, as the gimp
> > has _no_ control over the pixelsize of it's windows.
>
> I'm going to assume I misunderstood you here
Only partly. I was talking about dialogs, toolbox, menus etc... image
windows definitely are the exception (and indeed the gimp controls their
size ;). For example, I frequently hear things like "the menu is too full
and will not fit on 640x480".
> It does its darndest to make sure images will fit on a screen, and makes
Well, pressing "1" (100% zoom) frequently enlarges my window to (say)
10000x10000 pixels ;-> But it could be argued that the wm should limit the
window size to somethign sane (still, that windows "fit" on my virtual
desktop...)
> The same care has not been taken for all elements of gimp, and this
> sloppiness shows up in dialogs that run off even huge screens. I think
> that this is what you're trying to address, yes?
Exatcly not. Sure, you _can_ overcrowd a dialog, but the correct design
is to allow large dialogs/menus in a sensible way on small screens, for
example, by having scrollbars or displaying menus more intelligently,
_not_ by removing widgets in the hope "the user must use my font, my
x-server and my theme".
Here is a practical example: I cnanot select all file-formats in the
save dialog, simply because the optionmenu won't fit on the screen. Even
worse, when the dialog is near the bottom, I can only select the first 5
or 6 formatssince the optionmenu does nothing to ensure that I can select
everything (gtk+-1.2) ;)
Now, if you apply the "the menu is too full to fit"-argument then the obvious
solution is "use less file formats" or "use less layers" (gimp-perl suffers
from the optionmenu problem as well).
This example is extreme, but it illustrates my point. (My point does not
apply just before a release, of course, where such decisions must be made
sometimes).
The right solution in these cases is not to waste time thinking about how we
could use less file-formats, but use that time to get rid if the underlying
problem: limitations in gtk+.
BTW, I know that the gtk+ people actively do solve these problems. I
didn't want to rant in any way, I just wanted to remind people that one
should approach these problems carefully (I am a constant victim of
designs like: "well, the menu fits on _my_ screen, so you use too large
fonts") ;)
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@xxxxxxxxxxxxx |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
