[sugar] Supporting desktop applications, extending the EWMH spec
C. Scott Ananian
cscott
Fri Sep 19 16:37:31 EDT 2008
On Fri, Sep 19, 2008 at 3:56 PM, Marco Pesenti Gritti
<mpgritti at gmail.com> wrote:
> On Fri, Sep 19, 2008 at 9:43 PM, C. Scott Ananian <cscott at cscott.net> wrote:
>> Well, if there's only one window, and it's "stretchable", then your
>> decision is easy.
>> If it requests a fixed size, then you should probably decorate and
>> float all the windows. I could also see floating all fixed size
>> windows and tiling all "stretchable" windows -- that would make the
>> 'gimp' work nicely; all the palettes would be floating and all the
>> drawings would be tiled. And that's using only the "stretchable"
>> hint. =)
>>
>> I'm not entirely opposed to adding new hints for oddball apps, but I'd
>> like 99% of apps to work as-is, and from my review of the wms out
>> there, it seems quite plausible that we can do this.
>>
>> FWIW, the wm itself can add hints based on window class for outliers,
>> without requiring the outliers themselves to be changed.
>
> I see you mention three window managers on your page (including
> metacity). It would nice to see a quick analysis of their
> strengths/weaknesses for our use case...
I spent a while looking at documentation for all of them, but I need
to schedule some hands-on experience time. Some moderate
customization of the wm is probably necessary, since many of them ship
with "power user" defaults with keyboard window switching, etc. The
exact 'one virtual desktop per application' (well, maybe not a real
virtual desktop, but roughly) use case doesn't seem to be
out-of-the-box, but shouldn't be too hard. XMonad had erikg as a user
& advocate, but I worry about maintaining a Haskell app. It does have
a vibrant user community, though, and is easily customized. My
feeling is that metacity will be hard to upstream patches to, and it
would be more work to get working 'right', since it's pretty much
designed *not* to be extensible. But it is the "default wm" these
days. "awesome" seems to be on the ball wrt standards compliance, but
is extended in Lua (yet another language) and I don't know anyone who
uses it -- not that there aren't people, it just doesn't have a local
advocate. "awesome" and "whimsy" are among those listed on
http://www.freedesktop.org/wiki/Specifications/wm-spec -- whimsy is
written in python, which I like, but seems immature, which I don't.
whimsy also doesn't support the 'floating' layer necessary for apps
like gimp.
So, my initial impression was that "awesome" would probably work fine,
but that if erikg or m_stone wanted to hack on "XMonad", I could
easily be convinced of that, too. If "whimsy" sprouted decent support
for floating windows, I'd seriously consider it; it would be nice to
have a small hackable wm in our standard language. "awesome" was on
the top of my list to hack around with when I get time and see if I
could make it do the tricks I wanted it to do.
> If we go with this approach, Sugar itself is likely to require small
> or no changes and I can just let you and Sayamindu deal with all of it
The main changes required, I think, would actually be to the shell
code to make it happy running on a root window. There's some
reparenting magic that's done to make that work right; I was pointed
to the xpenguins source for information on what that involves, I don't
think it's a lot that needs to be done. We might have to tweak the
frame implementation so that it speaks the same standard
wm-communication language as the window selectors in the gnome panel,
if it doesn't already; haven't looked at that. And, of course, I
wanted to switch sugar to using the standard X activity startup
notification mechanism, and the standard desktop notification
mechanism. Those aren't strictly required for the wm switchover, but
would complete most of the work of making us a real citizen of the
outside world.
--scott
--
( http://cscott.net/ )
More information about the Sugar-devel
mailing list