On 04/11/2011 07:33 AM, Gabriel Beddingfield wrote:
Hi Rusty,
On Sat, Apr 9, 2011 at 11:53 AM, Rusty Lynch<rusty.ly...@intel.com> wrote:
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.
Thanks. This is a Good Thing. (However, I had one app that didn't
get full-screened -- so I had doubts about it. Now I know it's a Bug
To Be Filed.)
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.
<rant>
And since MeeGo UX is the Johnny-Come-Lately that just sort of showed
up one day with no design docs and no discussion -- seems like it
should be a little more aware of the fact that it's breaking the
Handset.
</rant>
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.)
OK. This is mostly good, IMHO. However, shouldn't there be some way
to support devices that don't have buttons? This is a new
requirement. (However, in my case this is just a hypothetical -- my
device has a button that appears as a normal keyboard keypress.)
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.
I haven't figured out how to close a task from the device switcher.
Can anyone explain it?
press-n-hold on one of the app icons to trigger a context menu, where
one of the options in the context menu is 'close'.
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.
OK, that makes sense.
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.
Agreed... a little communication with the community goes a long way,
though. :-)
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
Why not use the X11 window hints for this? (You know, like the
frameless window hint... or something akin to that.)
The point is to not make the applications have to know if showing a
decorator is a good idea for the specific device that their app is
running on. If your app is the only app showing the decorator, then it
just makes your app look second rate, like it doesn't really fit.
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
That's the thing... they had /just/ fixed it on the images I tried --
and then it got ripped out by the MeeGo UX.
I never saw it really work on any Intel device (where work means you
stop seeing crash reports when corewatcher is configured to submit to
the server without asking.)
...which is why people are asking, "Sine the MeeGo UX is shamelessly
breaking the Handset UX... is the Handset UX officially cancelled or
something?"
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
Yes, my wife's blackberry does this -- and a big part of the reason
why it sucks. It runs slower and more unstable over time because you
always have all these extra apps running. Do we really need to follow
suit?
I believe it can be done better. I don't have a problem with this on my
iphone. I did have period issues with my android phone before the last
upgrade (which is why i downloaded the app from the appstore for killing
arbitrary apps.)
--rusty
_______________________________________________
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
