Re: Icewm hacks for GNOME

[raster redhat com]

On 10 Sep, Marko Macek shouted:
->  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.

the efects are negligable if the shaped window is a child of a non
shaped window (ie icon in a box). - it isnt too bad. bg pixmaps
defintely make it quite sane.

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

root icons are a gmc issue :) not a wm issue

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

you coudl use input only windows above them - I thik its funky actually
- i rather like it :)

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

easy to fix via proper reparentign and regrouping icon iwndows into a
laregr parent window and just move that. :) 1 XMoveWindow will scroll
all icons then.

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

hmmm I still tend to disagree. - Good knowledge of X and use of its
features can make using iocn windows quite sane.. it just involves a
slightly different approach to using pixmaps (different mind set in
some ways).

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

still more work that doing.. um.. nothing.. :)

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

heheheehhehehhehe:)

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