>>> 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 _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel