Re: Icewm hacks for GNOME

On  8 Sep, Felix Bellaby shouted:
->  Miguel de Icaza writes:
->   > >   The .desktop files could store the window manager icons properly by
->   > >   including a list of all the appnames that an app uses with an icon 
->   > >   for each. The first of these icons could be used in the panel menu. 
->   > 
->   > What is the difference between this and having each one of our
->   > toplevels set the wmclass property?
->  The toplevels have to set the wmclass property in order that the
->  window manager can recognise which application owns them (and
->  distinguish between their various transients, ...) What I am talking
->  about is how the window manager translates that information into
->  icons. This translation is usually done using a window manager 
->  specific configuration file. 
->  My proposal is to put the necessary information into the .desktop 
->  files so that GNOME aware window managers can use the .desktop 
->  files for configuration. At present, there are no window managers
->  which support this form of configuration but it would be relatively 
->  easy to patch in support or use scripts to generate the configuration 
->  files needed by existing window managers from the .desktop info.
->  (This is the job done by wmconfig and similar packages)
->  In the longer term, the gnome-libs should support an X protocol to
->  tell the window manager which icons an application needs (so that
->  remote window managers work correctly). This protocol could simply
->  copy the information in the .desktop files over the X protocol to the

that would be highly bad. as in the kind of bad that a nuclear warhead
dropping on a large city would be. that would be bad. :)

->  window manager. Putting all the information in one place makes it easy 
->  for the user and allows legacy applications which do not support an
->  X protocol to be configured with the same tools as GNOME apps.

if you didn't know there already is a protocol for this.. ICCCM
supports app provided icons for iconification - the problem is 99% of
apps 1. do NOT even read the IconSizeHints the WM sets and roguely go
providing icons of any size they please - a WM has the right to ignore
these icons... We've ben coding icon support into Enlightenment in
recent times and its just hiting me now that I tyr and provide
support for app provided pixmaps and icon windows that this is the
case. I'm perosnally getting rather peeved at all these bad apps. they
are NOT a good example to set. A good solution would be for the app
to provide icon windows that the WM can resize and place where it
feels it is appropriate - the app will have to respond to configure
notifies for size changes and modify the window contents to match the
new size (eg scale the icon to fit the window) - this allows for static
AND active icons (ie icons that chnage their contents). You should
respect the icon size hints and provide an icon of that size. It is
better the app provides the icons via a standard PROPERTY HINT
mechanism like the rest of ICCCM's hints. There is already a proposal
for this

:) of which i have implimented most in E changed some due to redundancy
but pretty much have kept.

->   > > These changes would need slight extensions to the desktop-entry API 
->   > > but would make it easier for window managers to coordinate with the
->   > > configuration information maintained by GNOME. I would be happy to 
->   > > put through these changes if everyone agrees.
->   > 
->   > They seem like a good idea.
->  OK, I will have a look into it while I wait for other comments.
->  Felix

--------------- Codito, ergo sum - "I code, therefore I am" --------------------       /\___ /\ ___/||\___ ____/|/\___
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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]