[sugar] Supporting desktop applications, extending the EWMH spec

Mikus Grinbergs mikus at bga.com
Sun Sep 21 15:56:50 EDT 2008


>>> The principal goal of this discussion is to make the X Activity
>>> unnecessary by moving that functionality into Sugar's window management.

> what percentage of "legacy" applications are multiwindow? If it is a small
> percentage, then maybe we shouldn't be so focused on their support at
> the expense of the simplicity we are striving for in the whole.

I believe there are two separate subjects here.

One is:  _Given_ multiwindows, what is a good (for the Sugar USER) 
way to support them while keeping Sugar "simple"?  For myself, if I 
have the facilities to navigate between multiwindows (e.g., with 
alt-tab), I'm satisfied.  [The role Frame plays with multiwindows 
*does* need to be worked out - at the least, gray circles should not 
be left behind.]


The other is:  Provide an easy-for-applications-to-use framework for 
adapting how non-Sugar APPLICATIONS can run on that "simple" Sugar 
core.  This transformation may involve "sugarization", or the X 
activity, or the command line, or whatever.  [And not just "legacy" 
applications will be multiwindow, but also non-Sugar applications 
yet-to-be-developed.]


Just like effort is being devoted towards enhancing Sugar 
__development__ where a single platform would be limiting, effort 
ought to be devoted towards emulating application __execution__ 
requirements -- where Sugar's existing window design would be limiting.

I am not familiar with the X activity, but enhancing it to be the 
"intermediary" which converts windowing as requested by many types 
of non-Sugar applications into windowing as provided by Sugar -- 
that ought to be easier to do than to individually "massage" each 
such application to make it fit Sugar directly.  [Put any complexity 
into the "intermediary";  keep Sugar "simple".]

mikus



More information about the Sugar mailing list