Icewm hacks for GNOME

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

I have just hacked the icewm to bring up the GNOME panel menu from  
the root window and taskbar. This seemed like a lot less effort than 
trying to keep the config files in sync with GNOME. I will stick the
code in cvs if anyone is interested and Marco Macek agrees.

These hacks have made icewm a bit more cumbersome (using imlib and 
libgnome) but once the images are loaded the performance seems
comparable. I have not removed any of the original functionality 
but neither have I made icewm into a full scale GNOME app.

I have tried to use the panel icons everywhere (titlebars, etc.) so
that the GNOME menu editor can replace the icon configuration files.
However, I have run into some problems:

  icewm supports various X based protocols for setting icons
  (XWMHints, KDE and WIN_ICONS) and allows the user to set icons using 
  a configuration file indexed using X resource names. 

  Unfortunately, GNOME has yet to implement any X based protocol for
  defining icons and the .desktop file does not include the X resource 
  names used by the app (i.e. the "appnames" passed to gnome_app_new).

In order to use the .png images from the .desktop entries I have had 
to assume that the 'Exec=' filename in the .desktop file matches the
app's X resource name. This is a huge kludge (but where it goes wrong
it can be patched using the icewm winoptions file).

What about adding the following into the .desktop file standard? 

  The .desktop files could store the window manager icons properly by
  including a list of all the appnames that an app uses with an icon 
  for each. The first of these icons could be used in the panel menu. 

  This .desktop file info would supplement the window manager config 
  files rather than replacing them. As usual, icons set by the app
  using an X protocol would take precedence over both these sources.

  Setting the first appname equal to the app_id passed to gnome_init 
  would be a good idea since the SM code muddles appnames with app_ids.
  Using the executable name for this first appname is probably a 
  convention that we should encourage wherever possible.

These changes would need slight extensions to the desktop-entry API 
but would make it easier for window managers to coordinate with the
configuration information maintained by GNOME. I would be happy to 
put through these changes if everyone agrees.

The approach I have taken with icewm sets the window manager icons 
from image data using imlib. This allows the window manager to render 
the icons onto the appropriate visual and (should) allow it to perform 
scaling to reflect the dot per inch.

The existing X protocol standards for icon hints pass around fixed 
size pixmaps that have already been rendered onto some visual. This 
is slow, produces icons with restricted palettes and reduces the 
flexibility of the window manager. 

IMHO GNOME should seriously consider providing hints to window
managers using unrendered image data rather than using pixmaps. 
This would not match any ICCCM standard but I think window manager 
maintainers would jump at the chance to support a protocol of this 
kind. Any insane ones that refused could have their code patched 
in next to no time using Imlib. People lumbered with commercial 
window managers could just download a proper one instead.

Felix

All window managers are equal but some are more equal than others.