Re: Icewm hacks for GNOME

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

raster@redhat.com writes:
 > I know.. thats what i understood - highyl bad - not network transparent
 > - desktop files erefr to image files, (icons) exectutables etc LOCAL to
 > a machine.. they are not necessarily ont he machine your WM is runing
 > on.... basically u have to put the DATA there - not the files where to
 > get it from.. not everyone has a single workstation they run all their
 > X apps off (including WM).

OK, fine. Now I understand your criticism. I realise that passing any 
references to objects that are not actually located on the X server
can create problems when the wm and apps run on hosts which access 
different file spaces, etc.  

However, this is a red herring. My proposal suggests that the app sets
a filename on the top level window and that the wm reads the filename
and accesses the file. This protocol does not require that the app
has access to the file, it only needs to know its name. It get this 
through the desktop entry API in gnome.

The wm DOES need access to the file. However, I am proposing that the 
file is stored within the file system used to generate the panel
menu. So all that is needed is that the wm runs on the same host
as the panel. Since both processes are started using commands that are
compiled into gnome-session this is a virtual certainty.

Unless the wm runs on this host it will be unable to reproduce the 
panel menu as part of its root menu, a feature which I think is highly 
desirable. It will also have a hard time accessing the right copies of 
it own configuration files.

You could run your panel and wm on different hosts but unless you were
using a LAN the performance would be pretty awful. Any decent sysadmin 
will have given you access to the same basic file space on all the 
machines in a LAN. Using X over wider networks opens you up to 
security attacks. In these exceptionally rare situations the wm can
always fall back onto another protocol.

Remote apps face much more serious problems with gnome than any 
inconvenience in the protocol used to set a wm icon. They can not
access their desktop entry (this IS a problem with my proposal!).
They cannot access the preferences file associated with the gnome host 
they are displayed on. Indeed, where ever gnome uses files and file 
references they are in trouble.

If you are advocating that we move gnome over to a model which does 
not use filenames then I am right behind you! (o:

 > ->  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!!)
 > 
 > correction.
 > man XGetIconSizes
 > man XSetIconSizes
 > 
 > it's in Xlib - hell its part of core ICCCM - read up about it. :)

My mistake. I was basing what I said on the behavior implemented by Xt 
rather than XLib. Xt does not implement the icon sizes wm protocol 
This leaves it up to the VendorShell or the app programmer. Mwms
do not use this protocol (AFAIK) so Xm VendorShells do not bother to 
support it either. Xaw is the same. App programmers are probably
unaware that such an elementary function is up to them and that is 
why so few of them implement it. Obviously, the gnome libs must do 
better than this and actually support this sizing protocol so that 
all gnome apps have it enabled.

 > ->                                    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
 > 
 > not necessary - wm sees iocn window id, pixmap id and mask Id - it caan
 > query their sizes - if they dont conform the WM has many options.. not
 > accept them - forcibly resize or scale the data etc...

This is feasible for legacy apps that provide an ICON_WINDOW, ICON_PIXMAP or 
ICON_MASK but there quite a few which do not even do that: xterm & nxterm
are popular examples!

I am disappointed if E is planning to use the icons supplied by legacy 
apps without providing any means for the user to reconfigure them. 
IMHO the icons from Netscape and Emacs are going to look awfully ugly 
amongst all that enlightened elegance.

 > ->                I think you have to specify a mechanism by which 
 > ->  wms can get access to pixmaps in the sizes that they want to use.
 > 
 > easy - provide pixmaps way too large and let the WM scale them down to
 > wwhetever size it needs wherever it needs them.

A wm could implement this approach providing the apps responded to  
WM_ICON_SIZE hints that asked for very large pixmaps. But:

 > ->  3) The app returns pixmaps of those sizes.
 >
 > HELL I hope they do. cause currently none do.

Quite so, legacy apps just will not work with this scheme. The only
completely general solution is to provide a means of linking image files 
to X resource names and then getting the wms to render them.

Once you have done that loading image files for GNOME apps makes
perfect sense to me. Passing pixmap references around instead really
gains you nothing at all. It just takes longer.

However, the GNOME libs should obviously accomodate WM_ICON_SIZE 
requests for large pixmaps so that wm that do it like this will work.

 > ->  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.
 > 
 > sorry bad idea :( it may make it as far as a proposal but it wont make
 > its way into at least E - I dont think i can sanction a protocol that
 > isn't network independant.. :( sorry.. :(

As I have said earlier, unless you run your wm on a different host
from the panel then this protocol IS network independent.

If you are mad enough to do this then we fall back onto another protocol.

The only network dependencies lie inside the access routines used by 
gnome to get to desktop entries and will, presumably, disappear.

 > ->     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.
 > 
 > yet again.. X has somehting for the wm to set desired/allowed iocn
 > sizes. it's been there for ages. 

Fair enough. I withdraw this part of the protocol. Legacy apps don't 
support it. GNOME apps never really need: so chuck it out.

 > nup.. think about it - it woudl be better the wm says "I will need X
 > copies of an icon thus give me X window id's for those icons" (lets add
 > another property to the root window eg:
 > WIN_NUMBER_OF_ICON_WINDOWS(CARDINAL) = 10
 > the app reads this and sets a property on its window:
 > WIN_ICON_WINDOWS(WIN_ID) = [0x83000002, 0x83000004,.... etc ]
 > ie array of 10 window id's
 > the wm will map, unmap, reparetn, resize and move these windows to
 > wherever it sees them being useful. the app will get mapnotify events,
 > configurenotifies and can resize any icons itself to match the new
 > size. it can alos as an added bonus even have all the icons be active..
 > that comes for free with this.. :) it also means the app can chose the
 > visual and colors for the icon.
 > 
 > this covers everyhting your proposal has with much less work and
 > overhead, better expandability and more app control and window manager
 > compliance.

This provides no mechanism for creating a root menu that resembles the 
panel menu. In order to do that you need to load images from files and 
render them. IMHO this is really easy to do and once you have done it
you might as well use the same approach for all the other fixed image
icons that you need. 

It also provides no discussion of the problems with legacy applications.

How you can see your proposal as less work baffles me. Your own work
has made it extremely easy for a wm to open and render an image file 
using imlib to any scale. Reading a text property when it changes is
a few lines of Xlib code (which you can cut and paste in E).

The work on the app side is even easier. It need do nothing at all.
If it wants to support active icons then it needs to implement a
widget for them but that is inevitable.

As for the work in the gnomelibs, well most of it involves supporting
the ICCCM protocols used by existing wms. The work done to implement
my protocol, read a desktop entry and set a text property, is trivial.

I think the protocol I have specified is about as simple as it could
be and remains every bit as expandable as gnome itself. If and when
gnome becomes a distributed system then presumably remote apps will be 
able to access the RIGHT desktop entry (i.e. the one for the user who
is seeing the app window). This entry will contain a reference to the
image on that users system which can be passed to the wm in full
confidence the wm will be able to access it.

I am not removing any control from the app. It can set an icon image
and it can set an active icon window. I am merely proposing the API
which gnome should use to enable it do this.

I am not sure in which way I am supposed to be breaking wm compliance
by proposing a new protocol while intending to continue to support the 
protocols used by existing wms. You are proposing a new protocol yourself!

Felix