Re: WM hints interface

Federico Mena <> writes:

> >  I've been working some on putting more WM hint support
> >  into GDK.
> [snip]
> Cool!  We can now have proper hints for our windows :-)
> >  void          gdk_window_set_icon        (GdkWindow       *window, 
> >					     GdkWindow       *icon_window,
> >  					     GdkPixmap       *pixmap,
> >  					     GdkBitmap       *mask);
> Does the icon_window need to be specified?  Can't it just be built
> from the pixmap and mask?  Note that I read the window manager part
> section of the ICCCM some weeks ago, so I may not remember all the
> relevant issues.

The icon window is a separate thing from the pixmap/mask. According
to the ICCCM the pixmap must be a two color bitmap, and if you
want anything more, you need to provide your own window to draw
it. This is routinely violated by some applications (Netscape, etc.) -
I think the general understanding that the pixmap has the colormap/depth
of the root window. But since the ICCCM expressly forbids it,
and there will be problems with gdk_imlib as well, I'd like
to provide a convenient interface to doing it right. Plus,
applications can use icon windows to get animated icons, etc.
> >  void          gdk_window_set_decorations (GdkWindow       *window,
> >  					     GdkWMDecoration  decorations);
> >  void          gdk_window_set_functions   (GdkWindow       *window,
> >  					     GdkWMFunction    functions);
> Small change; the types of the masks should be gint or similar :-)

I assume you are saying this because of C++. If there was just
C, I'd prefer to leave things as above - it makes it clear from
looking at the header what type of argument is expected. But I
suppose C++ is an issue now.

There are a lot of other similar things that would have to be
changed as well. Just in gdk.h


All have bitmask arguments typed as the underlying enumeration.

> >   - The "most useful" of the hints should be settable with functions
> >     in the Window class - without having to force-realize the
> >     widget first. What is "most useful" is up for debate.
> What about having analogous functions for gtk_window that just test
> whether the window is realized or not?  If not, it would just remember
> the values and set them later on.

That sounds about right. Though really, there isn't much performance
advantage to storing them for later over force-realizing the
window right then and there, so it might not be worth the extra

> Good work!  I look forward to putting this in the handlebox and parts
> of Gnome.

I've already done the handlebox. (Two lines, twenty seconds)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]