On 04/09/2011 06:52 AM, Gabriel M. Beddingfield wrote:
On the latest daily builds for Handset and Tablet there are
no title bars (including app switcher button and app close
button). Will there be any? Nor do apps get automatically
expanded to fit the screen. Will they be?
I.e. are there plans one way or the other?
First... the easy one.... all normal toplevel windows should be made
fullscreen by the window manager, from my observations of the version of
meegotouch-compositor in Trunk, this is happening (where the easiest
example to test is to open the terminal.) If you are not seeing this
for one of your apps then we need to file a bug on the window manager.
Now for the harder discussion. Looks like we have a design mismatch
between what meego-ux is attempting to accomplish (which, btw, is not
tablet specific... I just happen to be on the hook to deliver this for
customers that are making tablets), and what the original MTF style
handset was attempting to accomplish.
For the specific example of window decoration, the meego-ux approach
makes demands on the device manufacturer that there must be hardware
home button of some form or fashion. This button must be visible to the
OS, and the OS must be able to detect the difference between press and
press-n-hold (and oh by the way... if you make that just look like a
normal key then it makes it much easier to get the device up and running.)
When the home button is pressed, you go to the homescreen. If you
press-n-hold on the homescreen, then we open a task switcher. From the
task switcher you can switch between active task, or close specific tasks.
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.)
Another idea for non-qml apps that i haven't discussed is instead of
just nuking the decorator, add a runtime config to decide if to use a
decorator or not, and if so then which one. Then the MTF style handset
could still have it's broken decorator (at least broken on any meego
image i have ever tried), and we could even turn on a hopefully working
decorator when running on something like one of the existing convertible
netbooks that don't have any buttons accessible when flipped.
These features are important because:
1. If someone develops an app for the netbook, then they
won't know that they're supposed to draw their own
title bar and exit button.
As mentioned before this is easy... no need for anyone to render a
window manager style toolbar.
2. Our company provides a lot of 3rd party, non-meego-api,
Xlib apps with our devices. These apps were not
written for phones, and are expecting the WM to provide
the buttons to exit the application. We would rather
not have to repackage mcompositor to get mdecorator
back.
again... no need.
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.)
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.)
Yes, I realize that mdecorator is buggy and even (at some
level) a broken concept. But I'm not really even talking
about mdecorator... I just need the basic WM functionality.
understood. hopefully my explanation above made sense, and for the more
sticky corner cases we can find a way to just make this work.
--rusty
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
