Re: Suggestions

["Guillermo S. Romero / Familia Romero" <famrom idecnet com>]

fbhome fabiogomes eti br (2000-11-25 at 1542.49 -0200):
> 	Please note that I don't have deep knowledge about X and GTK and I am away
> from the GNOME project since a long time ago, because of my work. Please
> don't understand these comments as flames. My intention is the best
> possible.

I am not a X expert either.

> 	The suggestions follow:
> 	* Window manager and MDI
> 	1. I think it is reasonable to move sawfish window decoration routines (and
> other common stuff) to a library, so that the window manager and GTK can
> access the code.

What if I use Window Maker? Or E? Or IceWM? Would this mean that GNOME
abandons the wm freedom? It is a nice feature it has since the
beginning.

> 	2. We should standardize this library, possibly in collaboration with KDE
> people.

One thing I would like to see is the projects saying clearly what they
will do (aka "we want to work in this as a team" or "we do not want to
work as a team"). No more "the other team blah blah" or "our team blah
blah". When speaking about collaboration, you have to say yes / no and
why (even if it is "we do not like, we want to work alone"), otherwise
better say nothing. It seems it worked with the wm spec, but with
other things they just waste time talking about nothing.

> 	3. Then, we should create a MDI Container widget using the library to
> decorate the MDI children and do other window managing stuff.

And then why have window managers if you do window managment via
widgets? Just wondering.

> 	4. This widget could support detaching children (by creating true windows
> from the MDI children);

In X windows are windows, even if they are look like other things. The
desktop background is one, and the window decors are more windows (so
one window are ten or so X windows), even menus are windows, IIRC.

> docking windows (ie: gimp toolbox) on the corners;

Corners? Why do I have to put windows in the corners? IIRC MDI apps
allow you to put windows anywhere inside the big window, even if they
go out (the out part disappears). Of course, being able to limit the
movement is nice, I have it in SF (set to some pixels, so I can move
windows out if I want) but it will annoy other people.

> a child list/task bar;

Working on that on the GUI list, so when you have too many windows and
too few space the task bar is usable (Whistler like, I believe, seems
to be the basic idea).

> small, 10-pixel high (or left-side with vertical text)
> title bars; rolling up; and other nice features.

Why left side? Why 10 pix? Why not the same font used in the rest of
titles? If I have set it to 15 pix, there must be a reason (I like it
or I need it to read it, are two reasons) and adding another config
item for fun when can be derived from a basic setting is not nice,
specially if it will be a feature targeted at newbies.

With rolling up you mean shade? Already done, and in some wm like E
you can have the effect animated and the vertical text too (someone
provided a small C listing that would be nice to see included in SF,
for the moment you can have the bar, but not the test, look how SF's
microGUI theme decors dialogs).

> 	   Most people will say that MDI sucks and don't like it, but Adobe
> Photoshop, mIRC and many other applications would suck if they didn't use
> MDI. The GIMP is a great app, but I don't use it because I get confused with
> the mess it causes with its big tool boxes. (Look at the task list!).

Use desktops / viewports as "big window"? Tell your windows to not
show in task list? You already can do that, and also tell your wm that
iconifing / deiconifing applies to groups, not to single windows. At
least Sawfish does. Use a Xnest to run applications inside?

Why not tell the wm that a group is the children of another window and
thus should never be allowed to go out of the space it has, and never
be below it? That way dettaching is just a toggle of "key in parent
area" bit.

> 	   I don't know if is it possible to move the window manager decoration
> routines to a library and use in GTK.
> 	Well, this is just a suggestion. :-)

It could, but that would mean the lost of wm independence and
reinvention of some wheels, I think.

> 	* GTK keyboard navigation
> 	1. Keyboard navigation and widget behavior should be standardized and
> documented. The current keyboard navigation is messy or the users (ie: me)
> don't know how to use it.
>          Isn't that bad to use the tab key to navigate through the widgets
> in Windows. At least it works.

You have it partialy right, but I think the main problem is that
coders do not set the navigation features right, cos some apps are
navegable (so GTK can do it). I can navigate the Gimp New window quite
fine. I have a similar problem with applications declaring groups, it
is possible, but now all do, or do it wrong.

> 	* Screen space
> 	1. We should consider wasting less screen space in GNOME widgets and
> applications. Outside the USA, big monitors (17-inch and above) cost mutch
> money and are not accessible to the majority of our users.

Yes, very true, at or Univ the new ones are 17" and not very good,
most of them are 14" o 15", and low quality (resolution and refresh).
Of course, you always get the "buy new computers" response when
problems about speed or such (they do not have response to "will you
give the money?" ;] ).

> 	   A good example of wasted screen space is The GIMP, because, as mentioned
> above, its tool boxes are messy and the widgets are too big. (Take a look at
> the layer toolbox).

Have you ever tried shade over? I have used 14" monitor at 800 * 600,
15" at 1024 * 768 and my machine now is 17" at 1152 * 864, and never
had problems, except when the space is really wasted and that some
monitors are really crappy and the refresh hurts (hi or low res).

Also, do people use autohide for panels? They should, or reduce panel
size to smaller kinds. OK, some people do not like it, but they should
know clearly that they can, and they do not use it cos they do not
want.

The main problem, and it is solveable, is the widget padding (big
areas with nothing, just a color or a pixmap), it seems too big and no
way to control it. Sometimes the app coders has to fix it, sometimes
the theme engine coders, and in any case it would be nice to be able
to set some values and be used in all themes you use.

> 	   Try using GNOME at 800x600 and you will see that the windows are
> extremely big and some applications get unusable.

Yes, until you find how. The only exception is the Motif heritage of
padding. Seems to be a big trend in X, but also seems to be changing,
luckly.

> 	* Performance 

I did, it was not bad (P166MMX, 64MB). Maybe cos I do not use fancy
things. One thing people do a lot is using all the fancy items
(including pixmap themes and animations) and the wonder why it is
slow. I know they do, I had admin some machines and some users add
things with no end. Other do not change defaults even if they do not
like them (so hard? lazzy users? never think about it?).

OTOH, when I try apps that are heavy GNOME ones, it is slow even in my
new machine. I dunno exactly why, but I do not like to see lots of
"gnome-name-server[xxx]: server_is_alive", each time I launch a GNOME
app it forks a name server even if not needed. There should be some
way to check if the name server is needed or not, so you avoid a
wasted fork and log line.

> 	* Customization
> 	  Customization is nice, but it should be measured with caution. Software,
> when very flexible, tend to cause confusion and be very difficult to use. A
> good example is Sendmail. We must read a 400-page book to (try to)
> understand sendmail.

Hehe, I think one of sendmail problems is the way it has the config,
not the freedom. I can set some apps with lots of options quite easy,
but they do not have a config file with values like "DS" that are hard
to remember but "SmartRelayHost" that once learned are easier.

>  	In the next few days, I'll try to write and post an article in some linux
> site regarding customization in user interfaces.

I think other way: bad defaults are bad, as someone remind me in the
GUI list. Customization is not. Most people that complain about how
Linux behaves never reconfigure things, so defaults must be towards
them, but never disallow customization, so others can have the
environment they want and not the standard.

GSR