Re: Icewm hacks for GNOME

[Felix Bellaby <felix pooh u-net com>]

raster@redhat.com writes:
 > ->  In the longer term, the gnome-libs should support an X protocol to
 > ->  tell the window manager which icons an application needs (so that
 > ->  remote window managers work correctly). This protocol could simply
 > ->  copy the information in the .desktop files over the X protocol to the
 > 
 > that would be highly bad. as in the kind of bad that a nuclear warhead
 > dropping on a large city would be. that would be bad. :)

Could you be a bit more specific Raster? (:

I think you may be misinterpreting me, I am NOT refering to the
protocol used to communicate with the X server over an X connection by 
Xlib and its extensions. Instead, I am referring to the various
processes of setting and unsetting properties on windows described
in ICCCM and helpfully also known as an X protocols!! :P

 > ->  window manager. Putting all the information in one place makes it easy 
 > ->  for the user and allows legacy applications which do not support an
 > ->  X protocol to be configured with the same tools as GNOME apps.
 > 
 > if you didn't know there already is a protocol for this.. ICCCM
 > supports app provided icons for iconification - the problem is 99% of
 > apps 1. do NOT even read the IconSizeHints the WM sets and roguely go
 > providing icons of any size they please - a WM has the right to ignore
 > these icons... We've ben coding icon support into Enlightenment in
 > recent times and its just hiting me now that I tyr and provide
 > support for app provided pixmaps and icon windows that this is the
 > case. I'm perosnally getting rather peeved at all these bad apps. they
 > are NOT a good example to set.

I am well aware that in practice ICCCM is a load of crap. (BTW, any
icon size hints are an extension of ICCCM -not part of the standard!!)
This is why it essential that the user has a means to specify icons for 
legacy apps that simply do not do it for themselves. We have two choices
about how we do this in GNOME:

1) We leave it up the user to tackle the configuration for themselves 
   using the wm's own hacked up mechanism (AFAIK no wm has a GUI for this) 

or

2) We provide a configuration facility within GNOME and make it easy
   for window managers to access the results of that configuration process.

I am proposing is the second option. It would be nice if we could 
patch up ICCCM so that the wm was given the impression that the legacy 
applications were complying with it properly. However, this would
require introducing a process which captured X events usually interpreted
by the window manager and might very well be impossible. Therefore, I
think we have to settle for providing wms with some source of
information that they can access reasonably easily. The
gnome_desktop_entry interface seems like a reasonable candidate for
this job. I know that it will not work when your wm and apps are
located on remote hosts but this is very rare.

 >                             A good solution would be for the app
 > to provide icon windows that the WM can resize and place where it
 > feels it is appropriate - the app will have to respond to configure
 > notifies for size changes and modify the window contents to match the
 > new size (eg scale the icon to fit the window) - this allows for static
 > AND active icons (ie icons that chnage their contents). You should
 > respect the icon size hints and provide an icon of that size.

This approach sounds fine for GNOME apps with active desktop icons.
Indeed, this is precisely how ICCCM handles active icons.
However, it would be rather expensive for GNOME apps with static
desktop icons and totally impracticable for specifying titlebar or
root menu icons. I think you have to specify a mechanism by which 
wms can get access to pixmaps in the sizes that they want to use.

 > It is better the app provides the icons via a standard PROPERTY HINT
 > mechanism like the rest of ICCCM's hints. There is already a proposal
 > for this
 > 
 > http://freeweb.pdq.net/redline/wmhints/
 > 
 > :) of which i have implimented most in E changed some due to redundancy
 > but pretty much have kept.

The quoted proposal outlines the WIN_ICONS solution adopted by the icewm.
I am currently discussing these issues with Marko Macek, the author of icewm.
I think that the WIN_ICONS protocol is basically sound in that:

1) The wm explicitly indicates that it supports the protocol,

2) The wm provides information about the size of the icons it wants,

3) The app returns pixmaps of those sizes.

This is all operates through an ICCCM-like protocol. 

However I think this approach could still be improved:

1) The app creates all the icons that the wm requests on start up.
   This is inefficient as the same app may be started many times
   during a session and the wm may never use some of the icons that
   are created (e.g. if the user never iconifies the window.)

2) The app creates the icons not the window manager.
   This constrains the wm in what it can do. There is no way that it 
   can perform complex resizing operations on the icon without
   requesting huge numbers of icons from every app and the wm has no 
   control on how the icon is rendered. 
   I can't imagine you like this very much, do you Raster? (: 
   Ah, icons wrapped round spheres ...
   (Of course, some apps may want to restrict the wm in what it does
    but they can use active icons (they probably want to anyway)).

3) The app and wm have to go through quite a complex process of
   exchanging properties over the Xserver simply in order to
   communicate one piece of information: which image is menemonic 
   for this app?

4) The protocol says absolutely nothing about how the user or 
   the rest of GNOME is involved in the process.

Consequently, I would propose the following protocol for use in 
GNOME for setting window icons:

   The wm sets an atom WIN_GNOME_ICON to indicate that it supports 
   the following protocols within the WIN_PROTOCOLS property of the
   root window

   a) Protocol 1:

	The app sets a text property ICON_FILE on each of its top
	level windows giving the image file used as a mnemonic for
	the window. This file will be in a format supported by 
	imlib and capable of resizing acceptably from around 16x16
	to 48x48 or larger. The png files in the panel menus 
	are suitable files. Changing the ICON_FILE property signals
	a change in the icon.

   b) Protocol 2:

	The wm sets a ICON_REQUEST property on a reparented top 
	level window which contains two numbers h and w. The app 
	catches the event notifying this property change and 
	responds by rendering its image file at height h and width
	w onto a pixmap with the root window visual. It then sets
	the ICON_IMAGE property on the reparented top level window
	which contains the rendered pixmap and mask. Changing the 
	ICON_FILE property still signals a change in the icon.

The first protocol provides maximum flexibility to the wm with minimal
work by the app and very little use of the X server. This protocol
would be the normal approach used by a wm on the same host as an app.

The second protocol is needed by remote wms. The window manager can
determine that the app is remote from the WM_CLIENT_MACHINE property.
It is also useful to wm that do not want to use imlib. Note that the 
wm initiates the request so that pixmaps are only rendered when 
actually required.

The wm can cache pixmaps in either protocol based on ICON_FILE names
(though some care is needed with remote clients).

The X atom names used above are for illustration. However, they must 
be distinct from any other atom names currently in use.

libgnomeui is responsible for implementing the GNOME side of this
protocol. It follows the following rules:

  1)  If the WIN_GNOME_ICON atom is set then 
	set the ICON_FILE property when the app has a static icon and
	set the ICON_WINDOW prroperty when the app has an active icon. 

  2)  ELSE if the WIN_ICONS atom is set and the WM_ICON_SIZE property
      is set on the root window then provide rendered pixmaps at the 
      requested sizes.

  3)  ELSE if the wm supports KDE_WIN_ICON (I am afraid I do not know
      how to check for this, I hope you can!) then provide an
      appropriate pair of rendered pixmaps.

  4)  ELSE Set the ICON_PIXMAP and ICON_MASK properties.

  5)  When the ICON_REQUEST property is set render that pixmap and
      set the ICON_IMAGE property.

This attempts to minimise the work that libgnomeui actually does without
depriving the wm of the best information that it can understand.

The API for icons works as follows:

  The gnome app widget has the following functions:

	void gnome_app_set_icon_file(GnomeApp *app, gchar* f);
	void gnome_app_set_icon_widget(GnomeApp *app, GtkWidget *w);
	gchar* gnome_app_get_icon_file(GnomeApp *app);
	GtkWidget* gnome_app_get_icon_widget(GnomeApp *app);

  It is permissable to set an icon file and an icon widget. This would
  be done by apps that want active windows and want to specify the
  images used in menus and titlebars.

  The icon_file should contain a suitable image.

  The icon_widget must possess its own X window so that it can be 
  reparented. AFAIK this is the only requirement that we need (?).

The icon files attached to appname are recorded in the .desktop 
file for the application. The gnome_app_set_file function alters 
the desktop entry and changes the ICON_FILE property. The 
gnome_app_set_widget function just changes the ICON_WINDOW property. 
During gnome_app_new the icon_file for the window is recovered 
using the desktop_entry API and the ICON_FILE property is set.

The API for desktop entries is extended slightly to accomodate one
image for each appname used by a gnome app. One of these is identified 
as special and used to generate the panel menu image. It is the icon
associated with the first appname in the .desktop file and can also be
accessed by passing a NULL appname to these functions:

	void gnome_dentry_edit_set_icon(GnomeDEntryEdit * dee,
					const gchar * appname,
					const gchar * icon_name);
	gchar* gnome_dentry_edit_get_icon(GnomeDEntryEdit * dee,
					  const gchar * appname);

This enables app writers to specify icons in the .desktop files and 
then forget about icons. Failing to specify an icon in the .desktop
file is not a complete disaster because of the user interface to GNOME
icons: 

  The panel menu editor is extended slightly so that it is capable of 
  editing more than one pixmap for each panel entry. 

(this needs a bit more thought as we would not want to leave the user
 choosing icons to match against appnames, something like the window
 title would be better. Also there are problems with applying any
 changes made in these entries to running apps.)

Note that apps can override user perferences if they want to without
needing to implement the protocols for themselves. However, I think
this may be a bad idea. I would advise that gnome_app_set_icon_file is 
only used in response to a user preference specification within the app.

Does this fill in some of the gaps in the existing gnome wm protocol
proposal in a way which is generally acceptable ?

If so then I will implement the gnome side of this proposal.

Felix