[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