[sugar] Supporting desktop applications, extending the EWMH spec

[C. Scott Ananian]

On Fri, Sep 19, 2008 at 4:50 PM, Sayamindu Dasgupta <sayamindu at gmail.com> wrote:
> Metacity was provided just as an example. The issue here is that we
> want to replace Matchbox with something which would let us support
> normal desktop applications better, ideally without requiring any kind
> of modification to the applications themselves. (better support, for
> instance means, not messing up The Gimp)

+1

> Agreed. But are sugar activities (or rather, should sugar applications
> be) the same as normal desktop applications from a window manager
> peerspective.

Yes, for the most part.  Inkscape or gnumeric running with one window
open should look the same as a sugar activity.  Things only start
getting interesting when I open two documents simultaneously in
inkscape.

>> When I'm running Browse in my window, and then select Fullscreen mode,
>> *then* it applies the full screen hint, and really *does* run full
>> screen.  This is just like Firefox does.
> Yes, that is why I'm still somewhat opposed to running all our
> activities with the "FULLSCREEN" hint permanently on - IMO, we need to
> differentiate between the two modes of an application or an activity,
> and the window manager needs to know about that.

+1

> GIMP is stretchable. It looks ugly when it is stretched too much, but
> you can stretch it or even maximize it if you want.

wow, i never realized this.  You're right.  I was just trying to
illustrate that the layout strategy doesn't have to be very
complicated for most applications.  Gimp does set reasonable window
hints, and simply falling back to "floating" mode with window
decorations when multiple non-dialog windows are mapped is a good
first-draft wm policy.

> Just a note that Xmonad seems to pull in 35 MBs of RPMs as
> dependencies. I'm not sure whether that is good for our storage space.

Wow.  I think part of the reason is that Xmonad supports recompiling
itself on the fly to allow you to dynamically edit the wm
configuration, and so pulls in the entire Haskell compiler and all its
libraries.  I'm willing to bet that a static configuration could be
made much smaller -- but that's clearly one of the issues that should
be relevant in the final choice for wm.
 --scott

-- 
 ( http://cscott.net/ )