Re: Suggestions

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

fbhome fabiogomes eti br (2000-11-25 at 2110.11 -0200):
>   From my point of view, the diversity of window managers in Unix is
> not a feature. It is a serious problem. If we had decent window
> management in X, people wouldn't need to write more window managers.

I doubt you are going to change that. BTW, some people could say the
same about diversity of desktops, BSDs kinds or Linux distros. ;]

>   This would be useful for toolboxes, like in GIMP, Dia, etc..

Would? It is already working, as well as being able to set some
resistance when you move a window near the border of another. Another
reason I like X wm and dislike Windows / Mac system (last time I
checked I was unable to set resistances, with most wm I can set on /
off, and how much if on).

If the wm does the window managment, I do not see any problem applying
the rules to MDI windows, what is more that would be consistent, cos
all windows behave the same way, no "if"s attached.

>   These small title bars would be useful for toolboxes and tool
> dialogs (like GIMP ones), to save screen space.

We just need somebody to patch the wms to do that. The X code to paint
fonts in four directions can be found in SF list, for example, it just
need to be modified and included in SF or any other wm (E already does
it).

BTW, you should count total pixels, I doubt they will save space, but
waste, cos that windows are higher than wider, so you have H * X for
vertical titles vs W * X for horizontal titles, where X is the title
fixed size (font size plus some padding).

The good reason to use them, IMO, is that for some windows they allow
you to read the title, when otherwise you will read a few letters due
title size (sometimes even buttons can not be displayed right).

>   I am not looking for ugly hacks to solve my individual
> problem. These I can do by myself.

The keep window over parent window is not a ugly hack, IMO, cos then
all software are pure hacks, it is like the trick that moves XMMS
windows all in group. What if we ask that feature in Sawfish list?
Well, I did, lets wait.  Maybe someone codes the "hack" and you can
set big parent windows and keep group inside soon.

Also, IIRC, when I used Window Maker I was capable of selecting
multiple windows and move all as group, so it seems we are talking
about things doable, but not just done as a direct copy of Windows.

>   Your solution works only if application developers specify which
> windows are treated by the window manager this way, or the end-user
> will never benefit from it.

Most things need colaboration, and from what I have heard, we are
speaking about one standard already set (ICCCM?). Imagine that coders
start to specify weird window sizes. They could, but it does not help,
and luckly they do not.

The same for groups, Gimp sets them, others do not (but should), so
should we try to change the all layers, or ask coders to play fair and
follow current rules? If some new rules are needed, they can be
created, like the wm spec, but maybe we just need the apply the ones
we already have.

I am talking with some coders about the group thing, some did not know
the purpose and some used it wrong. If you find apps with problems, I
think it is better to talk with the coders and request the change,
than following rare paths, specially if that paths would limit MDI to
some apps, when if coders can do it right it will work with all, be it
GNOME, KDE or a plain wm that implement basic standards.

>   One great feature that MS-Windows MDI system has is that you can
> navigate through the children (ie, with ctrl+tab) without touching
> windows in the outside.

I can too with groups (Sawfish at least). Have you investigated the
tools you already have? I think we should change our questions to
"where is" instead of "can I", cos most times someone appears saying
"you can, look here" (which sounds like "you do not look enough" if
the option is clear and like "coder just want to complex things for
fun" if the options is hidden somewhere). ;]

Also, docs seem to be lacking. Both for coders and for users. Asking
in lists solve that. I did when I found that the SF's window changer
(Windows Alt+Tab, the keys I want in SF) shown only one app and warped
the pointer, now my system shows the full list and the pointer stays
where it was.

>   I use the newest Helix GNOME with the default theme, no background
> pixmap, no pixmaps in menus, no pixmaps in the foot menu, and no
> pixmaps in the dialogs. The window manager is Sawfish and, believe,
> it is painfully slow when compared to Windows 98.

That is the problem, basic usage can be slow. Uumm, if you use SF,
check that the theme you have does not use pixmaps, but solid colors
rendered by the engine, that could speed up a bit. The rest is talking
with coders (some of them said GNOME was going to be fast, no?), or
send patches (what coders want, even if they did things so wrong that
fixing is a pain :[ ).

>   Bad defaults are bad. But very complex customization is useless.

Complex or free (here as allowed to do a lot)? You can have very free
config options, and it can be complex or not. Of course, the more
free, the more complex it can be if coder does it wrong, but not
necesarly. Also, you can have limited config and be hard (then you
wonder if the coder did it on purpose).

GSR