Re: Icewm hacks for GNOME

[raster redhat com]

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

but should not be relied apon.. some peoel wont use or dont use a
session manager - I may like to do:

rsh fast_server.domain.com DISPLAY=$DISPLAY /usr/local/enlightenment

infact i used to do this at universtiy because the worksations were dog
slow. i'd have small wrapper scripts to remote exec programs off
several servers to make life workable on my machine.. 

also.. what about file permissions.. what if the wm is runing as a
different user to the app - the app may see a different config under
differnt permissions? Then the app woudl have to retrieve and send th
actual umage data for the file to the WM - overhead.

the whole wm accessing files told to by the client is a bad thing (tm)
- most long time X coders will tell you this - it breaks the whole X
model.

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

all of this is quite posible via properties and resoruce id's.

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

why fall back? why not invent one that works in the first place? :)

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

those remote gnome apps woudl read gnome fiels local to their filing
system:)

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

HEEL Yeah.. actually I think we shoudl have an exam that requires
programers to read the entire Xlib function set before reeleasing any
apps:) you mightn't use them but tis damn handy to know what does and
doesn't exist - then peope would at thge leats know of this bit of
ICCCM and do the right thing (tm).

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

xterm +ai :) whee - icon window... but xterm is evil.. doesnt read
icons size hints.

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

if you specify a custom icon to E it will opverride the use of the app
provided icon. - it's already there :)

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

but all this woudl be solved by using window id's instead :) apps
manage the contents any way they (ro gnome-libs) pleases :) WM maanges
size and location and viability.

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

What i'm saying is - we can do better with less work! :)

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

no but ti provides a mechanism for any app in gnome to provide
sacalable ions for a WM to use :) thus we have a basis on whihc ot
build a menu wiht icons - app icons in titlbars, etc.

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

yes but its not network transparent - as long as the panel is alive it
can createX windiw id's for an icon - on configure notify call:
gdk_imlib_apply_image(image, window);

it can also call this on mapnotify :)

2 event handlers.. in gnome libs.. hwo hard can that be to get a
scalable interface with file system independance?

the panel can set a property on the wrrot window somehting like:

GNOME_ROOT_MENU_PXIMAPS(WIN_ID) [0x8000003, 0x8000005, ...]
GNOME_ROOT_MENU_TEXT(STRING) ["entry 1\n entry2\n, submenu1\n ...."]
GNOME_ROOT_MENU_SUB_MENUS(ATOM) [ NONE, NONE, PROPERTY_OF_SUBMENU, ... ]
PROPERTY_OF_SUBMENU(ATOM) [ GNOME_SUB_MENU_1_PXIMAPS,
                            GNOME_SUB_MENU_1_TEXT,
                            GNOME_SUB_MENU_1_SUB_MENUS ]
GNOME_SUb_MENU_1_PIXMAPS9WIN_ID) [ ..... ]

you get the idea.


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

it needs to negotiate the icon sizes witht he WM in your proposal -
more work than what I propose. All of this is in gnome libs anwyay...
so it is done for the app by the libs.

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

no you arent breaking it but in proposing a new one you need ti have ti
adopted - marco doesnt seem to like it - neither do i. I'm sure you
will get a similar response form other wm writers - we have our reasons
You are doign a valuable job in trying this - please continue - what I
offer is friendly advice form having been digging in deep Xlib
territory for a long while... it comes from experience. As is your
proposal of assuming common filing system doesnt work well - it also is
complex in having to neogtiate icon sizes withthe WM - also overhead in
providing all the icons before any are even used (pixmaps actually use
data - windows are cheap compared to pixmaps sicne windw doent have
data). thus we'd use the inbuilt serevr events as a protocol - re-use
of code - it would involve 2 event handlers on the app side (per icon -
easy to set up when you cerate the icon - same event handler woudl
handle all icons - just different window id and image to map to the
window).

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