And how could you cancel it? :P

I think the file chooser, can learn a lot from the way Canola structures its menus:

Screenshot:

Video: (pay attention to menu)
http://openbossa.indt.org.br/canola/...a_settings.mp4

For those that haven't used Canola, this is how it works:
1) You click to open the menu, and one 'card' slides out.
2) If you click an item on that card, another card slides over the first. It doesn't cover it completely, but leaves the left most edge exposed.
3) To exit out of the current card, just click the screen outside of the card and it slides away.
4) If the menu has more items than screen, you can slide the options on the card via inertial scrolling.

This system should work well for:
1) FILE CHOOSERS
2) MAIN PROGRAM MENUS
3) POP-UP DIALOGS

Not only is it hyper functional, but finger-friendly, and extremely good looking all at the same time (with or without the animation).


YARR!
}:^)~

Clapt'n

In this case, it could be cancelled with an exit button on the chooser itself.

Of course, I would prefer a Canola-style file-chooser.


YARR!
}:^)~

PyCorrupt

I was thinkin' that was one of the points to the Canola exercise in the first place... To help Nokia develop a finger friendly way to navigate a small touch screened, robust operating system without the need for a keyboard.

Right now Maemo is "Internet in your pocket". I'm now thinkin' its future will pro'ly be "Internet on the back of a car/airplane seat, on the wall just inside the doorway where a light switch used to be, at mega multi-station kiosks in travel terminals, on the outside wall next to the door of a main street business, etc".

It certainly seems that way, and I think I recall reading something similar. Interestingly enough, if you look at the new Fremantle application launcher, it looks more than a little similar to the Canola style launcher, so it seems that the project has influence! Of course, there are a few things that are still lacking from the fremantle demo, but it's still early...

I really like the canola interface, though there is one thing that gripes me about it: Selecting music with the inertial scrolling lists. I would rather that each song in the list had a 'play' button, OR there was a safe area that I could scroll with my finger without worrying about selecting songs. As it currently stands right now, if I have a song playing, and I'm scrolling through the list, sometimes my scroll is registered as a click, and I select a song I didn't want to play.

If this type of functionality was to be reproduced in the new Maemo UI, I would hope that it would be fixed to prevent false selections (which can be highly annoying, and time wasting). A simple selection button for each item on the list or a safe-finger-scrolling-area would work.

This is a VERY interesting idea, that can open up an entirely new market! Wow, what great insight. You are my new hero!


YARR!
}:^)~

Gran Capitarino

Kate Alhoa's makes it clear that the screen on the new devices is going to be 800x480 for sure.

The stylus keyboard is gone! Finger-touch and physical keyboard only.

GPS, vibration and accelerometer are included. We assumed this from the SDK, but these things weren't mentioned at last year's Maemo summit.

I found it interesting that QT applications will not just be compatible across S60/Maemo/PC but also Windows Mobile! No mention of Android or iPhone, but as Kate stresses they're not interested in low-resolution displays.

Regards,
Roger

question: does the hardware escape button cancel these dialogs?

Who told you you are going to have that escape button in RX-51?

o_O
you are right of course
I saw in kates excellent overview that there is a hardware menu button.
It seems odd to keep one of those but remove the arguably more important escape key :P
but lets not get into another d-pad issue.
kates summary goes over a lot of things and answers quite a number of questions I have been building about the overall lay of the land.

This is one of the wonderful benefits of a cross-platform UI like QT with many language bindings, an API for every OS feature a program could want, and written in a ubiquitous language (C++, I believe). This should greatly ease development for this platform, because you can develop natively regardless of your OS development environment -- assuming you exclusively use the QT API or your own portable libs (using OS specific libs in your app will obviously break compatibility). Put another way, it makes porting an app VERY simple task (a re-compile).

For example, Ms. Alhola's computer is a Macbook Pro (I think) from the shot on her blog. It doesn't appear to be slowing her down either!

I think QTs original goal was similar to Java's, only in a more natively-compiled way rather than a byte-language interpreted way. Write an app in QT, and you can compile and run it anywhere. Nokia was smart in championing the technology for Maemo. As it stands, it's probably the best example of a full featured OS independent layer for application development. Of the contenders, there is java -- criticised for a slow and bulky GUI. While there are many languages/libs that are cross-platform, these two provide a full cross-platform environment (GUI, network, FS, etc) for application devel.


YARR!
}:^)~

Multi-touch Corrupt