Re: Icewm hacks for GNOME

[raster redhat com]

On  9 Sep, Marko Macek shouted:
->  raster@redhat.com wrote:
->  > On  9 Sep, Felix Bellaby shouted:
->  
->  > 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...
->  
->  The right way to implement icons should not require any scaling/image
->  processing from the WM. This just slows it down when it has better
->  things
->  to do.
->   
->  > easy - provide pixmaps way too large and let the WM scale them down to
->  > wwhetever size it needs wherever it needs them.
->  
->  The reality is that small scaled icons do not look as good as hand
->  drawn ones. 
->  
->  > ->  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.
->  
->  Yes. The ICCCM is not too flexible here, but good enough for me.
->   
->  > ->  3) The app returns pixmaps of those sizes.
->  > 
->  > HELL I hope they do. cause currently none do.
->  
->  Yes. This is really bad.
->  
->  [proposal snipped]
->  > this covers everyhting your proposal has with much less work and
->  > overhead, better expandability and more app control and window manager
->  > compliance.
->  
->  It also has disadvantages:
->      - complex to implement in applications.

nothing gnome-libs can't handle for the apps - thats the idea - still
less complex than a to-fro neogtiation.

->      - requires Shape extension to get shaped pixmaps. This slows things
->  down.

no more than using a pixmap as a gc mask for XCopyArea. (the GC mask is
implimented as a series of clip rects)

->      - handling reparented windows in the wm is complicated (for example:
->        icons/titles in a listbox. Scrolling will be slow).

not really - try it someday :) unles you have 100's of windows (ie
100's of clientS) you will never notice and well - if you have 100's of
clients up you probably have a pretty good machine anyway (and X has a
limit of 1218 display connections so thus you're goign to have a
similar limit on clients assuming most apps only open 1 window- some
open more.. but you get the idea).

->      - Applications have to respond to drawing requests quickly,
->  otherwise
->        there will be holes in the window manager windows/titlebars,...

not too bad - same when you opaque resize a window - its a small small
small window - trsponse will be fast either way.

->      - dynamic icons can be just as easily done by changing the property
->        on the application window.

much more overhead - involes not just a conext switch to the server but
also a context swithc ot WM to handle property change - do we
re-negotiate all the icon sizes? what? then the WM discovers uh oh - it
has to XCopyArae and set masks for all icons for that app - finding
where they are on sacreen ans draw - if they are app managed windows
the WM can sit and ignore it all happily.

reparenting works wonderfulyl with the client windows themsleves.. why
not their icons? :)

->  Mark

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