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
