Re: GNOME wm hints proposal (Draft)

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

raster@redhat.com wrote:

> true.. I am just trying to minimise reporduction of current features.

I agree with reusing mwm hints, icccm hints where they do the job. 

> judging by the count of users of E - thousands. It's not my opinion -
> its the simple fact that people WANT fancy - look at managers who see e
> have theire eyes pop out and start asking about linux. It don't dictate
> that people want it.. they demonstrate it by the numbers of users.

Well, if I switched to E in it's current state, I would spent a lot of
time
hacking themes trying to make it work in a sane manner (fvwm* have the
same problem). Instead I wrote a window manager that works well by
default
without any configuration for anyone that can be productive with windows
or os/2 interface. This means mostly having a usable FEEL, because feel
is
*much* more important than look. Icewm provides configurable look, but
feel is mostly hardcoded to make things consistent and productive.
 
> ->  one? And what if your server is not the computer the app is running on? X
> ->  does that you know. Why stuff huge image chunks across the network using
> ->  the x protocols? My bandwidth is more precious than that. Not to mention
> ->  performance.
> ->  And since we can specify (a la the Style Guide) that GNOME-compliant apps
> ->  provide miniicon (as per the above GNOME hint) and an icon set (standard
> ->  hint). And one can set the preferred icon size for a server by a standard
> ->  property. Therefore we suggest that gnome compliant apps provide 3(or
> ->  whatever) standard icons (maybe 24, 48, 72? or 16, 32, 64?) in an icon set.
> ->  That way one size will be close enough. Besides, doesn't Imlib scale?
> 
> no - you didn't get me.. the APP re-renders the image into a pixmap +
> mask - the APP then chnages its icon pixmap+mask properties to the new
> id - the icon is already on the server. To cerate a pixmap the app has
> to dump that data across a network already. and how many times do you
> envisage a perosn changing his icon size preferences? the re-rrnder
> occurs int he client only about a request formt he WM stating that the
> icon is to be resized. the app compiles and re-renders at this size.
> 
> I am assuming tha ppcan scale - but unlike what you say, dont have
> "standard sizes" - that is a big mistake windows and macos makes, and
> has for years. the amiga had it right - just let apps create icons of
> whatever size. let the user change icons to whatever size and image
> they like.

I strongly disagree. We need standard default sizes in addition to 
any dynamic rendering. See below for some reasons.

> The wm sends a message like:
> 
> need icons 28 28

More than icon size is needed in a wm.
 
> now the app goes and re-renders its icon at 28x28, changes the wmhints
> to the new pixmap Id - the wm picks this up as a property change hint
> event - and icons then go change. this only happens if the preferred
> icon shize changes. dormally lets say the root window has an atom +
> data like:
>  PREFERRED_ICON_SIZE
>  "28 28"

I agree with this. I would like to see something like this:

WIN_ICON_SIZES array of (w,h) set on the root window.

applications sets 

WIN_ICONS array of pixmap,mask handles on it's own window.

However we NEED a set of standard sizes for several reasons:
  - rendering an icon to any requested size will probably produce uglier
icons
    than making icon for individial size manually.
  - applications might not be able to render icons, for example if they
are
    written in script languages.
  - rendering on the fly is possibly expensive and a waste of time
(imo).

Of course having this capability would be nice (can truetype handle
colors?)
 
> on startup the app looks at this for its icon size. Imlib would handle
> all the dirty work of scaling and creating the pixmap. the wm woudl
> just use that pixmap id.

Assuming you use imlib.
 

> ->  >actually here's a hint:
> ->  >apps use imlib for icons.
> ->
> ->  Why? Is GNOME going to stipulate that app developers provide 24+8 bit icons?
> 
> i dont' see where 24+8 comes into it?

Well each applications should provide icons in both 24 and 8 bit depths
in several standard sizes:

  16x16 x8 x24
  32x32 x8 x24
  48x48 x8 x24
  ...

I think we should also specify the default naming convention for icons
files.
Icewm currently uses:
  icon_16x16.xpm and
  icon_32x32.xpm,
but it does not currently handle 24bit icons. One problem is that
XPM is not very good for true color files (they are large) so using
something like ppm (binary) would be better.

 
> ->  >WM sets an atom HINt as to the range of sizes it will accept for icons
> ->  >(actually better it just sets THE size - the app may aspect correct to
> ->
> ->  Yes, this is in the ICCCM, exactly XA_WM_ICON_SIZE. Set it on the root.
> 
> ahh yes.. but if this changes? Well i spose the app could sit on
> anpropertynotify even on the root window.... this needs to be in a lib
> tho... and apps ned to go resize their icons on a change of this.

Yes. However this property is not quite adequate, because it can not 
adequately specify multiple desired icons sizes. It can only specify 
min,max size and step between them.
 

> 5. an icon is tiny data-wise. it'd rescale fatser than u can blink -
> well unless you request ionc sto be 1280x1024 - but well.. thats upt ot
> you then isn't it?
> 7. you don't have to make dozens of images - make one. imlib rescales
> it.
> 8. get a real artist to make your iconsa. programmers always make ugly
> icons - they have almost universally to date. look at xfig, infact
> almost all x* apps. they are badly drawn icons normally - imlbi can
> only help rescaling. it cant make bad data into good data.

I understood that app should generally draw an icon using graphics
commands, not scaling. Scaling icons does not produce acceptable 
results (ugly icons).

> P) but lets be pracitcal - who will impliment this first? we can go and
> define stuff - but no toher wm supports al of the advanced stuff u
> suggest. E will in a few months plus more. First in will deifne a
> standard. by the time thid debate finiashes and somehting is decided,
> then someone actually writes it... and then makes wm's comply.. E has
> done it. I can easily make E accept gonme hints - i just want to make
> sure we are desinging the right hints.

Well, I can implement my own proposals tomorrow and have them work,
but it is wiser to agree on a design first.

> and the pixmaps are already stuffed by many programs as their icons.
> just they are mainly ugly as a dog's beihnd.
I agree, most X programs have butt-ugly icons of random sizes, 
which makes them mostly useless.
 
> gnome has had ideas tossed around - no-one is doing anything. Ont he
> other hand ricdude is working on a sound manager right now - I gave him
> a pile of code i was workingon for this that actually worked - i was
> playing several mp3's and mods at once happily. it mixed and handles
> streams. it didn't handles uplaoding of samples etc. tho - and needs
> some extension. it has authentication and security aswell. The major
> work is done. It is not corba based - GNOME is playing wiht mico.. but
> mico doesn't want to play back much - there are no C bindings. as long
> as no c bindings exist, corba isn't an issue. the sound daemon i worte
> uses unix sockets for communication. it worked quite nicely. there was
> a small ibrary that was a close mimick of /dev/dsp and how it worked,
> so i quickyl ported mikmod and mpg123 to use it.

This is cool. It is probably good not to use corba for performance
reasons
anyway, (sound must be realtime).

Mark
-- 
... MouseDevice "/dev/null"
--------_--------------------------------------------------------------
Marko.Macek@snet.fri.uni-lj.si      http://ixtas.fri.uni-lj.si/~markom/