2011/4/10 Rusty Lynch <[email protected]>: > On 04/09/2011 06:52 AM, Gabriel M. Beddingfield wrote: > So... with this approach, no applications should waste screen space on a > home button or a close button. Everyone runs edge to edge, direct rendered > (except perhaps when we are doing window to window transitions or > compositing a system level overlay like the task switcher on top of the > app), all the time. > > Yes, this does present a problem when you take some existing device, > designed for something like Windows 7, and run a meego-ux based image on it. > > I'm open to ideas, but I think it would be a mistake to compromise the > ability to make competitive devices where from day one the device > manufacture is targeting the specific design approach taken in the meego-ux. > > One example that came up on an IRC discussion is to extend the basic > Window{} implementation add things like a home button when the device theme > ask for it (without the application developer needing to do anything.) > In my view, application developers also need inherit the window methods as function button handle from UX, they can override the default action implementation to customize their apps' functionality.
> >> 3. In the Tablet UX there's currently no way to close apps >> like chrome except to reboot. >> >> > > The idea is that for the most part we do like android and iphone, where > users shouldn't need to 'close' an app, but a thirdparty utility could be > create that closes apps.... and then the task switcher also presents a view > for "closing" active applications (but this isn't a display of all > processes.... just what we want to expose to the user.) > Yes, but why not give more choice to end users if they wanna close everything to save power? I think it is Meego, not another "Android" or "IOS". >> 4. These established MeeGo UI guidelines are now broken: >> http://meego.com/developers/ui-design-guidelines/handset/meego-basics >> (specifically the switcher and comments on fullscreen) >> >> > > A different design philosophy. I am hopeful we can find a way to make > mcompositor serve both needs. If not then perhaps we have to have two > versions of the package (with different patches) or just fork mcompositor > (which i really don't want to do.) I am just curious if have to have different WMs for different UX, whether can keep the compatibility for the same APP. Any CE product companies want their apps can run on the same OS between different device, smart phone, tablet, touch, netbook. One generation CE products only have a six month to one year lifetime. The manufacturers can't wait, and they need pick their "GUN" to shot quickly. The latter have the guns, the earlier face the dead, that's the war. If app develops have to submit different versions for different UX to APP store, it is a disaster. -- Best Regards Lin _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
