[Freeciv-Dev] Re: [PATCH] gui-gtk transient windows

[Mathias Hasselmann <Mathias.Hasselmann@xxxxxx>]

Daniel Burrows wrote:

> > I do. I do not see what's you problem with transient windows. They
> > behave like normal windows. That sawfish does not offer a minize
> > button nor a rollup button - that definitly a bug. (Among other
> > bug the sawfish developers call feature....)
> 
>   Ummm, the button placement in sawfish is determined by the theme.  
> Personally,
> I use a theme with only one button (a close button) on every single window,
> and like it very much.  Please drop the snide remarks, it's much easier to
> have a discussion if you do..

Oh... I really should not do snide remarks in a foreign language
not being completely concentrated. The bad spelling and disastrous
grammar is causes lets this look stupid ;-)

> > As written before: In IceWM, AfterStep, BlackBox, Enlightenment,
> > fvwm, fvwm2 and twm transient windows are normal toplevel windows.
> > You can still reach all the other windows, you can interact
> > with the parent window. You can use other transient windows of this
> > parent window. And you can move the transient window out of it's
> > parents (Since it is no child of this).
> 
>   The meaning of the "Transient" window type, as I understand it, it rather
> like the meaning of tags in markup languages like LaTeX in that rather than
> specifying how to display something, it specifies what it is.

You mean "transient" is an attribute. Agreed.

>   Specifically, "transient" -- as its name specifies -- is generally used for 
> windows which are interacted with for a short period of time, but which are 
> the focus of user input in the program for that time (I'm not familiar with 
> the official spec, but I think this is approximately correct. Club me over
> the head if it isn't :) ) 

Well I should have tried to translate this word. It is similar
to the word "transition" I known. You could be right...

>   Now, from that point of view, I don't think that any of the major dialog
> boxes in Freeciv are appropriately transient -- the science dialog, the trade
> dialog, etc, etc are often open for long periods of time in the background, to
> monitor what's going on.

I would say, most of those windows are something like palettes in
drawing programs. And in my opinion it should not be possible to
move this type of windows behind the main window. Since the 
"transient" attribute animates most window managers - I know - to
ensure this behavior and it seems not to causes any misbehavior
in other window managers, I think this attribute could be our
friend.

Setting the WM_CLASS attribute is also a good idea since it allows
you do fine tune your window managers behavior. But for the problem
I mentioned above it not anything more than a workaround, since 
setting the window's layer based upon it's WM_CLASS attribute also
affects  the usability of other windows which do not belong to
FreeCiv.

>   Things like the "what should this diplomat do?" dialog, the "trade caravan
> arrives" dialog, and the popup messages, on the other hand, are clearly
> transient windows -- if we aren't already marking them as such it's a bug
> and should be fixed.

Agreed.

> > The only difference is, that you can't put them into the background
> > by accident. And this feature, putting the message window, the
> > city dialog and other windows behind the main frame, nerves me.
> 
>   nerves: do you mean "bugs" or "annoys"?  (that's the most logical definition
> of "nerven" I can come up with for that sentence, and I assume that's what you
> meant?)

Doh. Obviously I picked up some slang somewhere. I liked the word
since it is similar to the German word for - you guessed it -
"to bug", "to annoy".

BTW: Was "doh" already part of the English language before someone
saw "The Simpsons"?

>   If you don't like this, I suggest you look into configuring your window
> manager to keep certain windows on top.  I don't know about IceWM, but every
> other modern WM I've used allows this.  (if they have separate window-classes,
> it's trivial to do this and all sorts of other usefull stuff in Sawmill)

I gave the answer above. IceWM can.

> > If not all people like it it should get a checkbox in the view
> > menu or the preferences box.
> 
>   that might work--although I'm not sure if you can change the type of
> a window after it's been created.  Does anyone know?  (I guess you could
> destroy all open dialogs and recreate them when this option is toggled; it
> probably won't happen often)
>
>   As we say on the sawmill list, long live the toggle button! :)

In GTK+ you can enable this attribute after the windows has
been mapped. But you can not undo this.

But you could interpret the toggle button as "Create *all* dialogs 
transient from now." This would make implementation quiet simple:

if (prefs.allDialogsTransient)
    gtk_window_set_transient_for (GTK_WINDOW (dialog),
                                  GTK_WINDOW (parent));


> > > So, we should decide what the windows are and how we are going to handle
> > > them. I don't se the message window and player windows as
> > > transient. Transient windows for me are typicly dialogs that you open, use
> > > and close.
> >
> > No those are modal dialogs. Well, sawfish suggests something else.
> > But beside the idea to utilize the Gtk for drawing this
> > application is completely a bug in my eyes.
> 
>   Yes, modal dialogs are usually transient.
> >From Webster's Revised Unabridged Dictionary (1913) [web1913]:
> 
>   Transient \Tran"sient\, n.
>      That which remains but for a brief time. --Glanvill.
> 
>   that's pretty much a perfect description of what "transient" means.

Strange, that most window manager interpret this attribute in
a way which makes it useful also for something which remains for
a long time... 

>   Now, looking in the GDK headers, I see the following window types:
> GDK_WINDOW_ROOT -- not useful for us
> GDK_WINDOW_TOPLEVEL -- a normal toplevel window
> GDK_WINDOW_CHILD -- a window which is a child of another window
>                     (like a button inside a window)
> GDK_WINDOW_DIALOG -- "used for any transient window"; I suspect this is the
>                     standard "transient-window" thing.
> GDK_WINDOW_TEMP  -- undocumented, scary :)
> GDK_WINDOW_FOREIGN -- a window which is handled by some other program, not
>                       useful for us
> 
>   Of these, GDK_WINDOW_DIALOG seems to be the only choice for either modal
> dialogs or transient windows.  (which are usually the same thing, as you
> pointed out above)

You looked into the wrong headers, I guess: The GDK library is
"just" a wrapper for the different Xlib APIs. GTK+ windows are
created by calling gtk_window_new (GtkWindowType). The
enumeration only contains three types: TOPLEVEL, DIALOG, POPUP.

Well, the GTK_WINDOW_DIALOG only seems to influence the
decorations style in GTK+'s reference window manager
"sawfish".

>   And are you suggesting that you don't want to use GTK+ for the client?  Have
> you tried the Xaw client?  That may be what you want..

I like GTK+. And the Xaw client does not builds on my system. I am
currently
not interested in finding out why, since I dislike most Xaw GUIs I am
using. But you say I should?

>   In any event, I have to say that your idea sounds to me like an abuse of
> the transient hint not unlike the abuses of HTML that we see out there, and
> if we implement it it should be an option defaulting to OFF.

Well the world we are living in is far away from being perfect...
But if there is this options it would please me. Unfortunately I
still have to finish some tasks....

And then there is Love Parade this weekend... And you definitely
are a sucker if you life in Berlin and work this long weekend... ;-)

Ciao,
Mathias
-- 
PGP: 1024-Bit DSA: ID 55E572F3, 1024-Bit RSA: ID EAAF7CF1
WWW: http://www.informatik.hu-berlin.de/~hasselma/
     http://www.dominanz-haus.de/