Hello all, So is there a consensus on this? Shall we fork mcompositor in this case? Or do you see a way to reconcile mcompositor for both MTF and meego-ux?
rs On 4/14/11 8:52 AM, "Lynch, Rusty" <[email protected]> wrote: >I was in fact speaking of a fork (where the meego-ux versoin of >compositor is really just a stabilized version 0.x.y), and Intel would >provide a maintainer who would also be on the hook to be the packager. >There wouldn't be a lot of development... really just plugging holes and >finishing up the transitions. > >But... perhaps you have an out with the plugin interface for >transitions. Is this something new? > >Some other conserns that i fear we will not have time to address: > >* decorated window: > >I see that newer versions of mcompositor have the notion of using >different decorators, but how about not using a decorator where non-mtf >and non-qml apps run fullscreen in direct rendering mode. > >* forced fullscreen windows > >Perhaps this is just a corner case of the decorator discussion... but it >appears like the MTF style UI allows for an application to run >non-fullscreen (i.e not edge to edge). > >* how to deal with building packages for MTF and meego-ux > >I see that the version of the package in devel:qt-mtf handles different >build options via the architecture, but what about verticals that want >to have both an MTF and a meego-ux flavor image? > > >On 04/14/2011 05:04 AM, [email protected] wrote: >> As additional notes from Abdiel: >> Window transitions are customizable using plugins. >> The plugin interface makes it easier to customize UX. >> We can have a "base" code and customized UX can be written using >>internal plugins. >> >> Fathi >> ________________________________________ >> From: [email protected] >>[[email protected]] on behalf of Boudra Fathi >>(Nokia-SD/Helsinki) >> Sent: Thursday, April 14, 2011 9:39 AM >> To: [email protected]; [email protected]; >>[email protected] >> Subject: Re: [meego-packaging] Packaging two versions of mcompositor >> >> >>> how about we just make this simple and create a new meego-ux'ish >>> compositor package, and back out all the meego-ux inspired patches to >>> meegotouch-compositor? >>> >> Could you clarify? >> >> Do you propose a fork of meegotouch-compositor? It will need a >>maintainer, not a package maintainer. >> >> Or do you propose to have 2 OBS projects with a common packaging like >>we have for cmake/cmake-gui (and some other packages)? >> In that case, a package co-maintainer is required to push the >>divergence and follow upstream changes (re-apply patches on top of a new >>release). >> >> Fathi >> _______________________________________________ >> MeeGo-packaging mailing list >> [email protected] >> http://lists.meego.com/listinfo/meego-packaging >> > _______________________________________________ MeeGo-packaging mailing list [email protected] http://lists.meego.com/listinfo/meego-packaging
