Re: GNOME icons again

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

Marko Macek writes:
 > My thoughts about this:
 >   1. The app icons (titlebar) are completely different from menu
 > generation.
 >      Specifying them must be network independant.
 > 
 >      I think this proposal should be split into two parts.

The proposal makes the app icons and menu icons completely separate 
from the perspective of the wm. They are only linked within the 
icon editor for the convenience of the end user.

ALL icons are accessed using completely network independent methods.
The wm can access the runtime icons for GNOME apps using WM_HINTS 
and other window based protocols.

The user icons also provide an alternative to a "winoptions" file for
legacy apps which is network independent and more efficient for the wm.

 > 
 >   2. Menus can be generated like you did in your icewm patches. If the
 >      wm can not read the menu file it can't run the program anyway.

The proposal includes a protocol to invoke panel menu items in a network
independent way!

 >      Complicating this with RESOURCE_MANAGER bloat is unnecessary.
 >      IMHO the use of X resource manager should be eliminated because
 >      it is slow (pattern matching the resources)  and constributes
 >      to most of the slow startup of motif programs. (Some 
 >      gtk programs also startup slowly, I hope this can be improved, 
 >      otherwise gtk isn't really an improvement from Xt/Motif).

ALL pattern matching would be avioded by passing the GNOME icon 
X resources in two properties GNOME_PANLE_MENU & GNOME_USER_ICONS.
All you need is XrmInitialize, XGetProperty, XrmGetStringDatabase
and you have installed a data struct that you can traverse easily
with XrmEnumerateDatabase and XrmGetProperty. This code is in Xlib
and difficult to improve on (read the sources in xc/lib/X11/Xrm.c).
Dismissing this as "bloat" does a serious injustice to the guys
at MIT.

Why should I violate the X model to pass the data in a different way ?
Using a mass of X properties as Rater suggested would be hugely 
inefficient in the number of X server accesses. Passing it using files
breaks network independence.

Xt searches a huge variety of sources for its resources (command line, 
app-defaults-file, fallback_resources, .Xdefaults, RESOURCE_MANAGER, 
SCREEN_RESOURCES) and sets a the huge number of fields using the
resources (almost every data member of every widget). Gtk has dropped 
all this but the speed improvement is hard to detect.

Widget start up faces real problems in geometry management, drawing
and interpreted language support. The Xt source does not waste much 
time in these areas so do not expect Gtk to be much faster. Indeed, 
it may be slower because gdk is slower at drawing than Xlib.

 >   3. As I said before, if root menu should be part of the GNOME
 > environment,
 >      it should not be left to the WM to generate.
 > 
 >      (When I split icewm into WM and non-WM parts, there will be no
 >       root menu in the WM, it doesn't belong there).

GNOME could provide a number of means of accessing the panel menu but
whatever it does there will still be menus created by SOME parts of
icewm (e.g. titlebar menus) that it cannot generate. The proposal 
makes the panel menu available through efficient network independent
protocols so that a launching facility can easily be built into any 
menu provided by any application including the wm. 

This is all a matter of user convenience. Requiring the user to go to 
special places to get access to their lovingly crafted launch menu
is a bad mistake (Win95). IMO the launch menu belongs at your finger 
tips everywhere in the GUI.

 > > When the WIN_GNOME_ICONS atom is not set then the gnome libs will:
 > 
 > Good, WIN_GNOME_ICONS support should be optional.

As long as your wm supports active icons in WM_HINTS then it supports
GNOME icons. Of course, it might not want to scale them and GNOME apps 
can provide pre-scaled pixmaps as an alternative. However, IMO scaling 
an icon window is easier than keeping track of icon pixmaps as well
as being more efficient.

 >  
 > > The image file for the user icon associated with a specific wm name
 > > or wm class is recorded in the .desktop file for the app that creates
 > > windows in that class. The files and resources are recorded as follows:
 > > 
 > > Icon=image.png
 > > Resource=resource
 > > Preferred=0
 > > Icon1=image1.png
 > > Resource1=resource1
 > > Preferred1=1
 > > ...
 > > 
 > > The "Icon=" field is used to generate the image in the panel menu
 > > and the corresponding menu icon. 
 > 
 > OK.
 > 
 > > Setting the "Resource=" field to
 > > match the wm class for the app (i.e. the app_id, as proposed above)
 > > will mean that this image will be used for the default user icon
 > > for all the windows created by the GNOME app.
 > 
 > Bad idea. There should be no need for Resource... If the
 > application wants the icons it should read the icon from the 
 > desktop file, theme, ... and set it to the appropriate windows.

NB: THE PROPOSAL ASSUMES THAT THE WM WILL NEVER READ DESKTOP FILES.

The proposal states that GNOME APPS will ALWAYS provide icons to the
wm by setting the WM_HINTS on their windows. 

The same can not be guaranteed for LEGACY APPS (ultimately, because 
GNOME can not select the MapRequest event). 

The mapping from WM_CLASSes to USER icons is VITAL in implementing the
user icon PROTOCOL used by the WM to discover which icons the user wants
to attach to LEGACY APP windows. The wm only knows the WM_CLASS: how
else could it find the icon which the user has assigned ?

Some wms might want to use the user icon protocol to discover the user
icon AS WELL AS obtaining the runtime icon from the WM_HINTS.

The gnome-libs will also use the user icons as a fallback when 
implementing the WM_HINTS protocols for GNOME apps. However, this will 
be completely opaque to the wm.

 > I read the proposal only briefly. I hope I haven't missed anything.

I hope the above makes the bits which I think you missed a bit clearer.
Focus on the wm interface. 

Felix