Re: White background in icons and WM integration

[Chris B . Vetter]

On Wed, 5 Dec 2001 00:43:34 +0200 (EET)
Dan Pascu <dan@services.iiruc.ro> wrote:
> >> comply to X conventions and protocols. As long as gnustep is an X
> >> client too, and tries to talk to other X clients, it should
> >> comply to the rules too. Else you need to create your own
> >> windowing system and be on your own.
> > Correct. And that's exactly my point. Window Maker sets a couple
> > of atoms, as it is supposed to be, to notify other clients of its
> > capabilities. However, what I was refering to is, that GNUstep,
> > that is, the backend, checks for specific Window Maker atoms and,
> > as far as I can see, relies on what Window Maker has to offer. In
> > itself not a bad idea. However, as Bjoern Gohla already pointed
> > out, _other_ window-managers are left alone.
> Hmmm, lets see. gnustep checks those atoms, because it needs info
> from them to be able to use the dock, and window maker's own
> appicons. do any other window manager offer a dock or appicons? if

Not the way Window Maker does. Afterstep and/or Bowman only offer
a dock, editable by hand, as far as I remember.

> not, how do you leave them out? You can't check for, or use a
> functionality they don't provide.
> if other window managers will provide these capabilities, then yes a
> more generic mechanism to find out about them would be nice, than to
> check for each window manager's atoms.
> like using generic names for those atoms:
> WINDOWMANAGER_WM_PROTOCOLS instead of WINDOWMAKER...
> but this requires all window manager developers to agree and set up
> a standard for this, so you can check a generic set of atoms to find
> out about a window manager's capabilities. (which is not something
> trivial)
> > Essentially, that means, IF you want full support for GNUstep, you
> > HAVE to use Window Maker, and THAT is NOT a good idea, in MY
> > (NSHAM) opinion ...
> that's because wmaker implements that extra functionality for you,
> and you check if its present and use it (in fact looking for those
> atoms, is a way to know if window maker is running or not so you can
> use its capabilities). It's not because gnustep refuses that extra
> functionality from the other window managers.
> You cannot have full support with other window managers because they
> do not implement the extra functionality for you, not because
> gnustep checks only for window maker's atoms. do they have docks or
> appicons? do they support gnustep menus? how do you want to have
> full functionality with them in this case?
> do you think that removing the checks for window maker's atoms from
> gnustep will improve interaction with other window managers? I think
> it will only make gnustep work worse with wmaker too.

True. But on the other hand, GNOME also, essentially, is just a couple
of libs, defining atoms and hints, a window-manager should honour.

Yes, GNUstep so far lacks the spread of GNOME, but wouldn't that be
the way to go? At least, in that case, if anyone decides to write
another (GNUstep-based) window-manager, he wouldn't have to have his
window-manager "pose" as Window Maker by using _WINDOMAKER_* atoms
and/or hints.

-- 
Chris