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?
> 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.)
> 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.
...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?
>> 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
OK... where's the link to the MeeGo UX design philosophy? :-)
>> 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, I can't thank you enough for taking the time to respond. This
has helped me a lot.
Peace,
Gabriel
_______________________________________________
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
