Re: Icewm hacks for GNOME

[raster redhat com]

On  9 Sep, Felix Bellaby shouted:
->  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

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).

->  
->   > ->  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!!)

correction.
man XGetIconSizes
man XSetIconSizes

it's in Xlib - hell its part of core ICCCM - read up about it. :)

->  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

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...

->  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.

but good design and forthought can make it work under both conditions.

->   >                             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.

easy - provide pixmaps way too large and let the WM scale them down to
wwhetever size it needs wherever it needs them.

->   > 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,

already in ICCCM - thats what i was bitching about before.

->  3) The app returns pixmaps of those sizes.

HELL I hope they do. cause currently none do.

->  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.)

hmm we might save.. ooh maybe 10Kb here and there... pffffft.
multiple icon windowsare saner - can be resized byt eh wm for whatever
sieze it wants.. on a configurenotify and MapNotfy the app can sett he
bg pixmap and have ti sized to fit the window... etc. if the "window"
icon isnt shown its a kb or 2 of serevr memory used.. didums.

->  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. 

see above for better solution. :)

->     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)).

hmm trust me.. I will never let opportuinites pass me by for a good
hack..:)

->  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?

yet again.. see widnow icon idea. :)

->  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.

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.. :(

->     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. 

->  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 ?

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.

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

-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
raster@rasterman.com       /\___ /\ ___/||\___ ____/|/\___  raster@redhat.com
Carsten Haitzler           | _ //__\\ __||_ __\\ ___|| _ /  Red Hat Advanced
218/21 Conner Drive        || // __ \\_ \ | |   \ _/_|| /   Development Labs
Chapel Hill NC 27514 USA   ||\\\/  \//__/ |_|   /___/||\\   919 547 0012 ext 282
+1 (919) 929 9443, 801 4392   For pure Enlightenment   http://www.rasterman.com/