Re: GNOME wm hints proposal (Draft)

[Max Watson <redline pdq net>]

At 10:56 PM 2/13/98 +0100, Marko Macek wrote:


>I think we really need to establish a common set of wm hints between
>different projects/WMs.
>I would like hints to be prefixed WIN_ instead of GNOME_WM_. (WM prefix
>is used by standard 
>X stuff, so I think WIN is a good choice).

Sound good.


>
>> These properties will be set up for an application in gnome_init, and
>> set to their default values (if any) in gtk_window_new. Or, if we do
>> not want to mess inside gtk, gnome_window_new.
>> 
>> The structure for GnomeWmHints:
>> 
>> struct {
>>   CARD32 flags;
>>   CARD32 decorations;
>
>These conflict with MOTIF hints. The application should probably define
>the MOTIF hints too?
>What happens if they conflict? Would it make more sense to simply extend
>the MWM hints?

Conflict? I do not see how. They are similar, but GNOME programs do not set
mwm hints, so it would be fine. I know that most of this stuff is similar
to already existing hints. But the existing ones are not being used
properly. That is the only reason I suggested this. If we want to go with a
more standard approach, that is great. If we can get everyone to agree. :)


>
>>   Pixmap miniicon;
>>   Pixmap minimask;
>
>This is not enough. I propose the following:
>
>WIN_ICONS as an array of Pixmap handles. 
>It can contain any number of Icon,Mask pairs (Mask can be None) in
>different
>resolutions and possibly bit-depths. We should probably specify that 
>application should define 16x16,32x32,48x48 and other icons in the depth
>of
>the root window). OS/2 also has the feature where size of the mini/large
>icons
>changes with screen resolution. It makes sense to have this, because
>16x16 mini
>icons are very small in 1600x1200 and higher resolutions.
>

This sounds like a lot of trouble and work. I am too busy writing apps to
sit around with the gimp for days on end writing icons. Perhaps there
should be a GNOME Icon Repository. That way, apps could select an
[mini]icon and bit depth, size, whatever from a common pool of images. I
know raster needs all different kinds of images for his stuff, but there
has to be a better way than this?


>>   Window gnomegroup;
>
>This also seems to already exist in some standard hints. 
>
I know. I said that. :) But please read my explanation in the proposal as
to why the standard "group" hint is inadequate due to inconsistent use
among different applications.

>
>Related to this: Does anyone know if setting WM_TRANSIENT to a hidden
>group 
>leader window is the proper way to do application transient window under
>X? 
>Adobe AcroRead seems to do this. I will be implementing this in icewm
>sometime
>soon.

I love new features in icewm! But why? Isn't application transient a
contradiction? Not to dis your idea, I would just like an example.

>An important issue: a gnome wm should not by default have a command 
>to do XKillClient in the menu. It is very dangerous if you miss a few
>pixels 
>(this is annoying in the default fvwm setups). The command could be
>available
>elsewhere (icewm has it in the window-list context menu).


Huh? What window-list context menu? That may be one of the things I
removed.:)
Or do you mean the Kill command from the Utilities off of the main menu?

>
>> Here is a tentative API for working with the gnome hints:
>> 
>> gnome_app_set_gnome_hints (GtkWindow *window, GnomeWmHints hints,
>>                            GtkFunction help_callback,
>>                            gpointer help_userdata);
>> gnome_app_set_system_menu (GtkWindow *window, gboolean remove,
>>                            GList menulist, GtkFunction callback);
>> gnome_app_set_help_button (GtkWindow *window, gboolean active,
>>                            GtkFunction callback, gpointer userdata);
>> gnome_app_set_miniicon    (GtkWindow *window, GdkPixmap *pixmap,
>>                            GdkBitmap *mask);
>> gnome_app_set_float       (GtkWindow *window, gboolean active);
>> gnome_app_set_gnomegroup  (GtkWindow *leader, GtkWindow *window);
>
>I think this would be more useful in the gtk. It would also have
>to support the Motif to be usable without gnome compatible wm.

I has been suggested that this actually belongs in gdk, which is correct,
since gdk handles the actual xwindows. I suggested gnome_app as a place,
because I was unsure whether or not we wanted to mess with gdk/gtk since it
is approaching 1.0.

>> gnome_app_set_help_button takes a window as an arg, followed by a
>> boolean to set/unset the hint, then a function to callback when the
>> button is pressed, and then the data to pass to it. At first I thought
>> that gnome should automatically set up an event box for the window
>> when the [?] button was pressed, maybe change the cursor, and catch
>> one click over a widget, then popup a tooltip with a lengthy
>> explanation of the widget, after which it removes the event box.
>> Then I realized this is more the domain of the app developer. One may
>> wish to simply popup the help system, rather than the mouse-over
>> tooltip thing. This needs the kinks worked out. Feedback please?
>
>The wm needs to send the message with the location of click?

This is kind of messy, I know. I was thinking when one holds the pointer
over a widget for a short time, one would get the "label" tooltip. After a
little longer time, the tooltip could change to a "description" tooltip.
The wm help button would simply bypass the first label tip, and indicate
that the next tooltip should be the longer "description" one. So the wm
would only need to send a client message saying "help button clicked."
GNOME (or gtk/gdk) would then switch tooltip modes internally. Remember, we
should not add any functionality that is not present when running under a
non-GNOME wm. Just enhancements. Does that make sense? (I have a cold, and
I am out of it right now.)

> 
>> gnome_app_set_miniicon is self-explanatory. Lets one pass a pixmap and
>> mask to the wm for use in conjunction with a window.
>> 
>> gnome_app_set_float should also be used mostly internally. But some
>> may wish to use it for non-modal (ie non-override redirect) splash
>> screens or whatnot. Everyone likes options, right? :)
>

>Perhaps it would be nice to have a WM_LAYER property. It could be set to 
>things like 
>  - Desktop    - bottom 
>  - Normal     - where application windows live
>  - OnTop      - on top of all app windows
>  - Menu       - on top of all app windows and OnTop windows 
>
>Wmaker has something like this. It needs more thought.

This is kind of nice. But is it a very radical modification to current WMs?
I really like the way my stuff works now. The whole point of not having a
GNOME wm is so people won't have to change their current setup too much, or
so I thought.

>
>> That is it for now. I would really like some feedback on this.
>> Additions, deletions (with reasons), and changes are more than
>> welcome. I feel this will be relatively easy to implement and am ready
>> to get started. I need to hear from wm designers too (raster, elliot,
>> any others) on what you want/can support in your window manager. I
>> will be working with icewm, and doing the mods to it as I go.
>
>As the author of icewm, I am willing to cooperate on this. Hopefully
>different WM developers can agree to a common set of hints.

Great! I was really not looking forward to having to do an "unofficial"
GNOME hack-patch to icewm without some endorsement from the author.
Whatever help you need with it, let me know. I know icewm's insides pretty
well. And I've added some stuff already. :)



> 
>> I toyed with the idea some properties for sound events, but this
>> really is not the domain of the wm. icewm handles this by generating
>> sound events for different actions which are caught by a separate
>> "icesound" program that dispatches to sounds. What was ever decide for
>> sound events in GNOME?
>
>icesound was an afternoon hack. I haven't really used it much, so it's
>likely it has problems (in the design).
>

I have messed with it. It works some, but segs on me a lot. But I believe
your idea is the way to go. Raster has some similar stuff implemented in E
(or will be implementing). So maybe some compatibility is in the future?

I am glad to see this section of GNOME is coming together. This project has
really matured quickly over the last couple of months.  Keep up the good
work folks!


M.Watson redline@pdq.net