Re: Icewm hacks for GNOME

[Marko Macek <Marko Macek snet fri uni-lj si>]

raster@redhat.com wrote:
> ->      - 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)

But is only used when drawing. If you use shaped windows they have
effects when generating expose events and hit testing.

Problem with shaped windows (last I tried gmc/E)
  1) gmc - you really should be able to click onto a transparent section
     of the root icon. This really should be fixed. Transparent text
     is even worse.

  2) enlightenment - icons that change look on mouse enter sometimes
     start flipping because the active icon has different transparency
     than inactive one. Really bad.
 
> ->      - 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).

I open 30-40 Netscape browser windows at simultaneously every day (I
would probably open even more, but 64mb is not enough and netscape
doesn't scale very well at 40 windows anyway).

This would require (in icewm) 40*4 icon windows of size 16x16 + 
40 windows of 32x32 (current implementation). 
In icewm you can see:
 - 4 mini icons  (titlebar, taskbar, window menu,  window list box) for
each      window at once or 
 - or 3 mini (no menu) + 1 large (large icon is used in Alt+Tab). 

Since netscape only has one icon for the browser they would be all the
same.
Scrolling the list box would be slow since all windows would have to 
be moved. Not to mention ugly effects at scrolling that usually occur.

Unless active icons are updated very often (quake in the icon ;-),
this is a better way to go. 
 
> ->      - 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

wm gets PropertyNotify, requests property (this is the only problem if 
you update icons often) and issues setClip,drawPixmap,resetClip.
 
> reparenting works wonderfulyl with the client windows themsleves.. why
> not their icons? :)

Perhaps. I might try to implement it to see how it works. I just have
to figure out how to simulate netscapes bloat. :)

Mark
-- 
... null
--------_--------------------------------------------------------------
Marko.Macek@snet.fri.uni-lj.si        http://ana.fri.uni-lj.si/~markom/