Things i really don't like ...

[Master of Gizmo]

There are some things in fremantle i really don't like and which i think nokia should re-think. This thread is to voice these things and to see whether others see the same problems (in which case nokia might want to re-think things) or if they are fine with this (in which case i might want to re-think things).


It will not contain libosso-help anymore and thus won't have any central help system at all anymore. The idea is that every application now does its own help system however it wants. This is imho a very bad step backwards as it will just cause help systems to disappear
The finger scrollable text windows (HildonPannableArea with GtkTextView inside) don't support text selection. Thus most applications like modest and e.g. the web browser won't allow to select text for copy'n paste (this is still possible using the cursor keys but only if the text is actually editable and has a visible cursor)


For me both of these are really show-stoppers and i can't understand why they are happening. We just learned that even apple can't live without copy'n paste on the iphone ...

Feel free to add more ...

[Bundyo]

The file chooser dialog is really limited on screen estate. What should happen if an user has a folder with 1000 of files? Break his fingers or gain arthritis?

[BrentDC]

I have to agree on both points (though, I didn't know osso-help was disappearing :().

As for the second, there is a bug filed in the Bugzilla; please vote it up if you feel it's worthy!

https://bugs.maemo.org/show_bug.cgi?id=4619

[benny1967]

Thus most applications like modest and e.g. the web browser won't allow to select text for copy'n paste

bummer.

i hadn't realized that.

i write almost as much as i read, using quotes from other websites as much as possible.

not being able to copy text from a browser window to, say, an email or another browser window where i write a new blog entry is just like not having a browser at all: i'd need to wait until i'm home. :(

they need to find a way around this that's generic and doesn't rely on the author of a specific software to implement a solution.

[daperl]

This all sounds very strange. Yesterday I installed 3.0 on my iPod touch; the cut-and-paste is very slick and very fast. What is going on here? Nokia better get it together.

[ragnar]

Guys. Might I suggest continue this thread once you see the actual release and software and see what is there and what is not there and how things are solved. Really. :)

[GeneralAntilles]

Guys. Might I suggest continue this thread once you see the actual release and software and see what is there and what is not there and how things are solved. Really. :)

So, what I should be taking away here is that text selection is confidential?

[ragnar]

No, it's just that you're making rather strong jumps, say from a HildonPannableArea property and how it is set to being able or not being able to do something.

It's no more or less confidential than anything else there.

[sjgadsby]

...it's just that you're making rather strong jumps...

Agreed on:
Thus most applications like modest and e.g. the web browser won't allow to select text for copy'n paste
But the foundation,

The finger scrollable text windows (HildonPannableArea with GtkTextView inside) don't support text selection.

appears to be a legitimate developer concern. How should programmers using the SDK proceed in building fully functional Maemo 5 applications when this GTK control would traditionally be called into play?

I'm all for
...continue this thread once you see the actual release...
in regards to hardware details, Nokia apps, and fancy task switchers, but in this case developers have hit a what appears to be a seriously troublesome point in the SDK, its documentation, or both. Unlike "guess the directional control method and win a prize", this is actually hurting development, and therefore, working against the goals of the SDK. If there's a misunderstanding, a simple fix, or a work around, I think an explanation of it would be greatly appreciated.

[qwerty12]

Here's another one - https://bugs.maemo.org/show_bug.cgi?id=4618

I remember getting pissed off at Nokia because they wouldn't include the rotation patch into the Diablo kernel and xserver. But it would be a supported mode in Fremantle and that was, er, the end of that bug. Now, the bug above points out something wrong with the way Nokia's doing this implementation and it's a WONTFIX. The WONTFIX issue never bothered me before (say, except for the diablo rotation bug) but if Nokia are already giving out the WONTFIXes - for legit bugs - in their new OS, then they can **** off.

[Thesandlord]

wow, thats a stupid bug. Even the current portrait mode GTK dialogs work fine. Its a step backwards.

It seems really easy to fix, just move the yes/no buttons to the bottom, and give the text all the space it needs on top. How hard is that...

[Bundyo]

Probably very hard if it wasn't taken into consideration from the beginning...

[lma]

Feel free to add more ...

Input methods.


3-row hardware keyboard (not officially confirmed, but rx51_keymap in the kernel matches the "Rover" image pretty closely).
Stylus keyboard: gone (http://maemo.org/development/sdks/maemo5_alpha_overview/).
Autocomplete: gone (https://bugs.maemo.org/show_bug.cgi?id=2505#c12).
Layout switching on the hardware keyboard: gone (https://bugs.maemo.org/show_bug.cgi?id=2501#c17).


From an outsider's point of view it sure looks like someone @ Nokia has declared war on text or something, because this makes no sense. Input was one of the real gems in maemo and apart from a few bugs here and there didn't need "fixing" :-(

[daperl]

Why wouldn't they have just left it open? "Not enough resources" is generally not a good reason to close a bug.

[javispedro]

For the panning & selecting issue, what do you think about using "double tap"/"tap, tap, hold" to start "selecting mode"?

I saw that on some other handheld application; it felt so natural I am still sometimes double clicking on my desktop computer to select text.

EDIT: Autocomplete gone? Man, and I tough iPhone OS 1.0 was the original "dumb-down" target.

[GeneralAntilles]

I saw that on some other handheld application; it felt so natural I am still sometimes double clicking on my desktop computer to select text.


This is how it works now, so I'm not sure why it would change.

[javispedro]

This is how it works now, so I'm not sure why it would change.

:p So natural I did not even notice I was still using it. :D

[GeneralAntilles]

Why wouldn't they have just left it open? "Not enough resources" is generally not a good reason to close a bug.

Perhaps an artifact from their internal tracker where sitting bugs are a big no-no.

[daperl]

Perhaps an artifact from their internal tracker where sitting bugs are a big no-no.

Oh, well, if that's the case, I would just change the verbiage from WONTFIX to FEATURE.

[nilchak]

Guys. Might I suggest continue this thread once you see the actual release and software and see what is there and what is not there and how things are solved. Really. :)

But that's the whole point of the SDK in beta - that we (knowledgeable guys, not me) check it out and test file bugs - well in advance of the actual software release.

I will be all too glad to see the solution (if the problem mentioned of cut-n-paste in indeed a issue) as you mention in the final release.

[qviri]

Guys. Might I suggest continue this thread once you see the actual release and software and see what is there and what is not there and how things are solved. Really. :)

Is there any particular reason you are unable to state "the finger scrollable text windows support text selection" (or, alternatively, "the finger scrollable text windows support text selection")?

[Master of Gizmo]

Guys. Might I suggest continue this thread once you see the actual release and software and see what is there and what is not there and how things are solved. Really. :)

This sounds like you are suggesting to stop development around fremantle specifics until we see the final device. I was tempted to work around those limitations, but i'd really be pissed to see that all this effort was a waste of time if the final device comes out and things will actually be resolved by then.

So the precise question here: Should developers work around those limitations now? Or should they stop working on issues related to the help system and the text selection because nokia will come up with updated sdks/apis once the devices are released.

I really REALLY don't want to spend too much time coding work-arounds if the missing functionality will re-appear magically in some months.

[ragnar]

This sounds like you are suggesting to stop development around fremantle specifics until we see the final device. I was tempted to work around those limitations, but i'd really be pissed to see that all this effort was a waste of time if the final device comes out and things will actually be resolved by then.

So the precise question here: Should developers work around those limitations now? Or should they stop working on issues related to the help system and the text selection because nokia will come up with updated sdks/apis once the devices are released.


No, I wasn't trying to suggest to stop development. I more like tried to say that don't jump into conclusions about whether something can be done or not based on some properties of some UI component. For instance, just quickly checking the specs there is a specified way to highlight text in the browser.

Looking at the bug https://bugs.maemo.org/show_bug.cgi?id=4619 "Panning and scrollng are mutually exclusive" says exactly that. Comment #5 "I've been told that the pannableareas 'enabled' property can be used to switch between selection/pan mode." I'm no developer, but I read the bug that you can place a button in the UI to switch the property of that component. (Or does somebody read that in some other way?) In many/most cases you don't need to have text selection available, that's part of the reason why it's not universally available.

[benny1967]

Autocomplete: gone (https://bugs.maemo.org/show_bug.cgi?id=2505#c12).


what?!?!?!

i cannot believe all this. i wish i'd never looked at this thread. :(

[conny]

As I reported the two mentioned bugs, I have to say: I don't like it too ;)
Here is another one which affects portrait mode:
https://bugs.maemo.org/show_bug.cgi?id=4617

Well basically this mean that the usage of the portrait mode is not recommended and if you (as developer) want to use it, you'll have to write (mostly) a complete new UI. Then if you still want to maintain the Diablo version you have to maintain 3 more or less different UIs:
Diablo / Fremantle landscape / Fremantle portrait.

That's not fun at all and I can see how developers will drop support for Diablo quite quickly...

Not UI related, but another thing that wont get fixed in Fremantle:
https://bugs.maemo.org/show_bug.cgi?id=2557

[Architengi]

Here is another one which affects portrait mode:
https://bugs.maemo.org/show_bug.cgi?id=4617

Well basically this mean that the usage of the portrait mode is not recommended and if you (as developer) want to use it, you'll have to write (mostly) a complete new UI. Then if you still want to maintain the Diablo version you have to maintain 3 more or less different UIs:
Diablo / Fremantle landscape / Fremantle portrait.

That's not fun at all and I can see how developers will drop support for Diablo quite quickly...


Portrait mode is vital for a phone if N900 is a phone...
First of all the T9 touch virtual keyboard should appear in portrait and all the applications should have support for portrait mode.

[Master of Gizmo]

I'm no developer, but I read the bug that you can place a button in the UI to switch the property of that component.

You are no developer, so i assume you are an ui designer. You basically say that you won't provide a generic solution to this, but instead want every developer to invent his own solution for this.

I haven't seen yet how text selection works in the browser, but we can safely assume it's not the same button doing this in osso-xterm. And modest is imho dealing with this by trying to avoid text selection at all and using all kinds of "hyperlinks" wherever possible. Is that true?

These are three example handling text selection completely different. All those third party guys out there will also come up with their own ideas. The same will happen with the help systems. I am really concerned that this will result in too many completely different solutions addressing the same problem. This will confuse users and this is what gui frameworks are there: To give users a consistent ui.

I'd understand (albeit not appreciate) if you'd just remove those features and say "We don't want help systems nor text selection in fremantle ... period). But you say "We still want this, but we remove support from the frameworks and want individual solutions instead. I don't understand the idea behind this. Imho you are risking pretty inconsistent user interfaces this way.

[qgil]

Hi, wouldn't it be better to have separate threads to discuss different topics?

I'm only speaking as a Maemo & Fremantle user here.

It will not contain libosso-help anymore and thus won't have any central help system at all anymore. The idea is that every application now does its own help system however it wants. This is imho a very bad step backwards as it will just cause help systems to disappear

Have you used such Help in Maemo applications? I know I haven't. Even in my full GNOME desktop I have used the Help system only in few occasions after several years. The apps I use in Maemo tend to be self-explanatory. If I have questions I find the answers online.

What are your experiences with Help systems in mobile devices?

The finger scrollable text windows (HildonPannableArea with GtkTextView inside) don't support text selection. Thus most applications like modest and e.g. the web browser won't allow to select text for copy'n paste (this is still possible using the cursor keys but only if the text is actually editable and has a visible cursor)

In terms of text selection, Modest is more an exception than a norm because it still uses gtkhtml. So please don't make conclusions for the whole platform based on it.

Let's see this from a user point of view:

- The Maemo selecting behavior up to Diablo could be improved specially in scrollable areas, according to many sources e.g. this old bug (https://bugs.maemo.org/show_bug.cgi?id=166). This justifies the action to change things in Fremantle, where scrolling and panning has a more important role.

- The Maemo browser has a specific gesture to activate text selection. Any application using the browser engine to render its own content can benefit from its gestures at will, including text selection.

- Text selection is not an issue in non-scrolling/panning areas. Developers can offer an interface where the user just needs to move his finger from beginning to end of the text selected.

What cases fall out of these two categories? Developers can still offer the change from pannable to selectable areas in one click. The assumption is that this separation will make life of users easier than in Diablo and previous versions.

Let's discuss examples of real applications, please. In which ones do you expect selecting text is going to be a problem?

[qgil]

The file chooser dialog is really limited on screen estate. What should happen if an user has a folder with 1000 of files? Break his fingers or gain arthritis?

Can you list use cases for choosing files?

You might have 1000 songs or videos but you are supposed to browse them with your media player.

You might have 1000 images but you are supposed to browse them with your image viewer.

You might have 1000 files inside a single folder that are not songs, videos or images... what are they? Do you really have that? Going through 1000 files (and perhaps only 100 too) is going to be an unpleasant experience no matter how much real estate you have for that.

Regular desktops are minimizing the relevance of the file manager accessing the files you want from applications or global searches. I'd say file managers are even less relevant in mobile devices.

Do you think Maemo users start opening the File Manager to find something? What?

[fms]

You might have 1000 songs or videos but you are supposed to browse them with your media player.
No, I am not supposed to browse them with my media player. I am supposed to open a file manager and see these 1000 songs, as files, copy them, delete them, rename, them, etc.

You might have 1000 images but you are supposed to browse them with your image viewer.
Wrong again. I am supposed to open a file manager and see these image files there. Furthermore, the file manager should let me apply normal file operations to them (copy, move, delete, rename, see metadata, see content).

You might have 1000 files inside a single folder that are not songs, videos or images... what are they?
They may be arbitrary documents in arbitrary formats. Why am I supposed to tell you what my files are?

Do you really have that?
Yes, I do.

Going through 1000 files (and perhaps only 100 too) is going to be an unpleasant experience no matter how much real estate you have for that.
No, it is actually quite decent, as long as you have the right file manager. Both FAR Manager and the standard Windows Explorer handle this situation quite well by letting you sort files by different characteristics (names, dates, sizes, etc.). The Maemo file manager is obviously quite terrible at this task but it does not mean we are not supposed to do it, as users.

Regular desktops are minimizing the relevance of the file manager accessing the files you want from applications or global searches. I'd say file managers are even less relevant in mobile devices.
Both of these statements are really opinions, not facts.

Do you think Maemo users start opening the File Manager to find something? What?
Yes, Quim, they do. And suffer too, because the current file selection dialog is such a royal pain in the tukhes.

[ragnar]

No, I am not supposed to browse them with my media player. I am supposed to open a file manager and see these 1000 songs, as files, copy them, delete them, rename, them, etc.

Wrong again. I am supposed to open a file manager and see these image files there. Furthermore, the file manager should let me apply normal file operations to them (copy, move, delete, rename, see metadata, see content).


Sure you can do that, but the File manager is not the optimal UI for it. The optimal UI for media is different from the optimal UI for images. The File manager UI optimizes for file management tasks whereas the applications optimize for the consumption tasks.

I/we don't certainly expect users to use the File manager for consumption tasks, because there is a far better UI for that elsewhere.

In general we have things like Tracker system etc. so that the users don't need to care about about file locations.


Yes, Quim, they do. And suffer too, because the current file selection dialog is such a royal pain in the tukhes.

The file manager full UI is btw a different beast than the file selector dialog.

[attila77]

Don't know about you guys but I gave up on file manager (the Diablo one) long ago. As much as I dislike it, I just have Midnight Commander in the personal menu. Unsexy ? Yes. Console reminiscent ? Yes. Totally finger unfriendly ? Absolutely. Built in sshfs and ftp clients ? You bet ! Functional ? Hell, YES !

From what Quim wrote I'm under the impression they view files less and less as 'files' in the classical sense, and users are not supposed to muck around with them - it's the job of the application to handle them. I always hated that approach (mostly because the applications sucked big time at managing their own files) I understand the approach as an attempt to 'simplification' of resource management (for better or worse).

[qgil]

Here's another one - https://bugs.maemo.org/show_bug.cgi?id=4618

I remember getting pissed off at Nokia because they wouldn't include the rotation patch into the Diablo kernel and xserver. But it would be a supported mode in Fremantle and that was, er, the end of that bug. Now, the bug above points out something wrong with the way Nokia's doing this implementation and it's a WONTFIX. The WONTFIX issue never bothered me before (say, except for the diablo rotation bug) but if Nokia are already giving out the WONTFIXes - for legit bugs - in their new OS, then they can **** off.

If you read through that bug report you will see that the boundaries for a fully supported and fully tested portrait mode for all widgets depends not only on Hildon (we could still handle that alone) but also probably on plain GTK+ (upstream code with different stakeholders, priorities and speed).

We have pushed the widgets and test cases that were essential for the applications we wanted to show in portrait mode, and I can tell they look "just normal" in Fremantle.

Automatic portrait mode for everything was never promised and we were clear in the Fremantle alpha release that landscape mode is default as usual and developers need to do specific work to get portrait mode as well.

The reasoning for the wontfix for Integrate screen rotation patches into stock kernel and X server (https://bugs.maemo.org/show_bug.cgi?id=3519#c21) stands: we don't think the Maemo UI is ready or even should behave in portrait mode in all cases. If some things go wrong in some cases that is perhaps ok for a community patch but not for a commercial release.

Landscape mode with optional portrait mode makes more sense for what Maemo is intended. Maybe in the future the Maemo specific UI and the upstream toolkit will be more portrait-ready, but this is not the reality we have now.

Said that, a developer willing to have a portrait or a landscape/portrait application with Maemo 5 can do it.

[fms]

Sure you can do that, but the File manager is not the optimal UI for it. The optimal UI for media is different from the optimal UI for images. The File manager UI optimizes for file management tasks whereas the applications optimize for the consumption tasks.
Wait. Marketing gibberish aside, media and images are just files. Are you telling me that the File Manager is not an optimal UI for managing files??? :)

I/we don't certainly expect users to use the File manager for consumption tasks, because there is a far better UI for that elsewhere.
I use kitchenware for consumption tasks. I use file managers for managing files. The current Maemo File Manager is absolutely terrible for managing files.

In general we have things like Tracker system etc. so that the users don't need to care about about file locations.
From what I know about Tracker, it is going to be a separate pain for the users (think current metalayer-crawler squared). But let us not discuss Tracker here. What I find highly unusual is that we now have two Nokia employees in this thread trying to tell us that we are not supposed to manage files with the File Manager. Are you serious, guys?

The file manager full UI is btw a different beast than the file selector dialog.
Neither works well with a sizable number of files. Neither tries to maximize the number and length of shown filenames (a must for decent file manager or selector). So, both have to be fixed somehow.

[qgil]

(this is what I was fearing when asking for separate threads for each problem)

The Maemo file manager is obviously quite terrible at this task but it does not mean we are not supposed to do it, as users.

If you have 1000 files in single folders and you want to dive through them searching songs, videos or images then you can always find an alternative to the Maemo file manager, not intended for your purposes.

At the end the file manager is an application just like the browser of the media player. If you don't like what comes pre-installed then you can try something else.

[qwerty12]

but also probably on plain GTK+ (upstream code with different stakeholders, priorities and speed).


Correct me if I am wrong, but don't Nokia already fork it and modify it where necessary?


The reasoning for the wontfix for Integrate screen rotation patches into stock kernel and X server (https://bugs.maemo.org/show_bug.cgi?id=3519#c21) stands: we don't think the Maemo UI is ready or even should behave in portrait mode in all cases. If some things go wrong in some cases that is perhaps ok for a community patch but not for a commercial release.

I have (by and large) gotten over it not being included in Diablo (and I guess it does not matter any more as I do not see the "Software update notifier" blinking to tell me of a software update - not that I expect one) but in the hope that it'd be better in Fremantle.

And we've seen what happens with community patches; why would anyone invest time into fixing Nokia's problems?


Said that, a developer willing to have a portrait or a landscape/portrait application with Maemo 5 can do it.

Oh, they can (have a portrait app that is), but how many will looking at bugs like the one mentioned?

But, anyway, I thank you for giving me a calm answer considering the profanity in my original post.

[qgil]

What I find highly unusual is that we now have two Nokia employees in this thread trying to tell us that we are not supposed to manage files with the File Manager

No, you have two Nokia employees that are spending a big chunk of their busy morning trying you to explain why things are designed and implemented the way they are.

Midnight Commander makes happy attila77 but won't make happy many users. Your solutions proposed here will make you happy but we believe they won't make happy many users. For instance, the file manager showing more entries means that each entry has less real estate, compromising finger usability.

Is it a coincidence that those of you complaining about the real estate usage of the file manager complain also about finger optimization vs stylus usage? Of course not. You are consistent with your priorities, and we try to be consistent with our priorities as well. Not easy to make everybody happy.

[daperl]

On the subtopic of "item" sorting, I sure hope Maemo 5 uses a different technique for sorting bookmarks. The Maemo 4 bookmark sorting is so slow and uncommunicative that I consider it a bug.

[attila77]

If you have 1000 files in single folders and you want to dive through them searching songs, videos or images then you can always find an alternative to the Maemo file manager, not intended for your purposes.

It's not just the amount. The file manager tries to enforce a certain layout of your home directory. Which is cool for new guys, as they don't need to face the standard unix dir layout. Unfortunately there are just too many applications who do not respect this layout, which make a separate file manager (MC, emelfm) quite needed. And if you already have those, then file manager quickly becomes a stepchild.

EDIT:

Midnight Commander makes happy attila77 but won't make happy many users. Your solutions proposed here will make you happy but we believe they won't make happy many users. For instance, the file manager showing more entries means that each entry has less real estate, compromising finger usability.

I understand that and at no point did I say everybody should use MC to achieve Maemo World Domination (TM). It was just a personal experience I wanted to share (for the record, I don't use/like MC on my desktop - it just fits my Maemo use-case better than the official File Manager). If you ask me what I would recommend (which you don't) I'd say have a basic (finger, fixed dir layout)/advanced(stylus, no dir layout restrictions) file manager mode. I think that would really bring World Peace in Maemo File Management. ;)

[qgil]

As I reported the two mentioned bugs, I have to say: I don't like it too ;)
Here is another one which affects portrait mode:
https://bugs.maemo.org/show_bug.cgi?id=4617

Another problem hitting GTK+ limitations directly. Yes, Maemo choose to fork GTK+ in the past, the price was big and in Fremantle we have put a considerable effort into pushing any Maemo specific changes to GTK+ trunk as well. Anyway, that bug hasn't been resolved yet and is being investigated by GTK+ maintainers as we speak.

Well basically this mean that the usage of the portrait mode is not recommended and if you (as developer) want to use it, you'll have to write (mostly) a complete new UI. Then if you still want to maintain the Diablo version you have to maintain 3 more or less different UIs:
Diablo / Fremantle landscape / Fremantle portrait.

That's not fun at all and I can see how developers will drop support for Diablo quite quickly...[/QUOTE

We are telling developers that landscape mode is default and recommended. This works well for Diablo compatibility. If you go portrait you will have extra work and you will create more gap between your Diablo version. If you are not happy about this, stick to landscape mode.

Again, it would help having real examples of Diablo applications that would benefit from seamless portrait mode without specific UI rework (if the application framework was perfect and prepared for that).

[QUOTE]Not UI related, but another thing that wont get fixed in Fremantle:
https://bugs.maemo.org/show_bug.cgi?id=2557

That report is open as well. It says:

This is not planned for Fremantle. Setting target milestone to Harmattan, although it is not confirmed yet.

The request makes sense but its implementation is complex and we prefer to concentrate on other bugs/features first.

Sorry guys but it makes little sense to have a discussion of severa unrelated problems in a single thread. I'm happy continuing the discussion in specific threads.

[lma]

At the end the file manager is an application just like the browser of the media player. If you don't like what comes pre-installed then you can try something else.

Well, yeah (and that's absolutely a good thing), but that doesn't mean the built-in applications shouldn't strive to be the best-of-breed at what they do. Tablets are quite powerful devices but rootfs space is limited. The "WONTFIX because there is a community alternative" approach means that by the time you install (random examples) claws, evince, leafpad, canola, pidgin, tear (eventually) etc you'll have very little space left. Not to mention that currently filling the (JFFS2) root filesystem eats up RAM as well.

IMHO is there is (for example) a PDF reader in the shipped firmware it should either be the best reader available, replaced with the one that is, or at least made removable (not depended on by osso-software-version-xxxx).

[fms]

If you have 1000 files in single folders and you want to dive through them searching songs, videos or images then you can always find an alternative to the Maemo file manager, not intended for your purposes.
Actually, I can't at the moment (all file managers available for Diablo have drawbacks, although Midnight Commander works best, with hardware keyboard open). The problem also affects the standard file selector though, so people who just want to open a file in some application have to wait for a long, long time if there is a lot of files in the current directory and/or its immediate children.

At the end the file manager is an application just like the browser of the media player. If you don't like what comes pre-installed then you can try something else.
I actually agree with you on that. What bothers me though is that very few of the applications Nokia ships with Maemo appear to be usable. If you want to read mail, you install Claws (because Modest just does not work). When you want to manage files, you install Midnight Commander (because File Manager does not work on big directories and only shows few filenames). When you want to listen to music, you install Canola (because Maemo Media Player lacks features and relies of metalayer-crawler to find music).

So, yes, I can abandon all the apps Nokia ships with the device and use third-party ones. But this will mean that Nokia utterly failed in delivering a device that is usable out-of-the-box. When you ship a device, you have to ship it with apps that actually work and are comfortable to use. Instead, you seem to choose a really small number of artificially created "use cases" and tell everyone not fitting them to just bug off. Don't you think it is wrong?

[fms]

Is it a coincidence that those of you complaining about the real estate usage of the file manager complain also about finger optimization vs stylus usage? Of course not. You are consistent with your priorities, and we try to be consistent with our priorities as well. Not easy to make everybody happy.
For the record: I did not complain about that. Yet. :)

[qgil]

IMHO is there is (for example) a PDF reader in the shipped firmware it should either be the best reader available, replaced with the one that is, or at least made removable (not depended on by osso-software-version-xxxx).

Fully agreed.

[conny]

Again, it would help having real examples of Diablo applications that would benefit from seamless portrait mode without specific UI rework (if the application framework was perfect and prepared for that).
Ok, many applications would still need some tweak here and there. But the transition from a landscape UI to a portrait UI would be much easier for the developers if they would get something working quickly. I agree that the process should not be completely automatic and that (as it is now) the developer should mark it´s program as "portrait ready".
Still I can see many use cases where a _dialog_ is still needed in portrait mode. And having to work around an issue like that is more then adjusting the UI a bit.
Also blaming that issue on Gtk is questionable. I mean did Gtk change dialogs in a way that the buttons are displayed on the right side of a dialog?

Sorry guys but it makes little sense to have a discussion of severa unrelated problems in a single thread. I'm happy continuing the discussion in specific threads.
Well this all has been discussed on the developer mailing list in several threads. I think the intention of this thread was exactly to talk about _all_ things people are worrying about regarding Fremantle.
I think it´s good to have this thread and to discuss the software and developer platform instead of always talking about the hardware. At least the software is testable right now.
Also I think it´s good to make those bugs visible to a broader audience so that they have the option to vote on these.

[Bobbe]

I'm sorry, but I read the whole thread and some things remain unclear. After all, will I or will I not be able to select text in Fremantle like I do in Diablo? Will I or will I not be able to cut copy paste?

Honestly, even though I understand the concern with portrait/landscape on the developer's side, I understand Nokia's position on the matter. Honestly, I do.

As an engaged user and nothing more, I so far have had no problem with the file manager, if for no other reason because I knew, by simply looking at it, that it couldn't handle large file collections. It just couldn't. Once again, as just an engaged user I don't miss that feature much. I have large collections of music but only need Canola to use it. Now, from the same engaged user perspective, shipping the next OS with such a poor file manager together with such a limited media player and no pre-installed Canola (or another media library manager just as functional and user/finger-friendly) would be a huge shot in your own foot. COMMERCIALLY speaking.

(make modest better too. And implement system-wide, easily accessed search features that include e-mail body search. But I digress.)

Finally

So, yes, I can abandon all the apps Nokia ships with the device and use third-party ones. But this will mean that Nokia utterly failed in delivering a device that is usable out-of-the-box. When you ship a device, you have to ship it with apps that actually work and are comfortable to use. Instead, you seem to choose a really small number of artificially created "use cases" and tell everyone not fitting them to just bug off. Don't you think it is wrong?

Truer words have seldom been spoken.

[ragnar]

Wait. Marketing gibberish aside, media and images are just files. Are you telling me that the File Manager is not an optimal UI for managing files??? :)

I can't really understand how you can read my sentence of "The File manager UI optimizes for file management tasks" into "Are you telling me that the File Manager is not an optimal UI for managing files?"

No?


What I find highly unusual is that we now have two Nokia employees in this thread trying to tell us that we are not supposed to manage files with the File Manager. Are you serious, guys?


No, we're not saying that. File manager is specifically optimized for managing files.

What we're saying is that managing files != consuming files. File management is for copying/moving/sorting/creating folders etc., consumption is for browsing, filtering, consuming etc. The optimal UI's for those two streams of tasks are different.

File manager should optimize to show attributes of files that are relevant to the file management tasks whereas a consumption UI should show content in a way that optimizes for consumption. For consumption you don't care about file sizes and dates and file names, but you want to see the metadata presentation of such content, and convenient handles in the UI to consume in different manners. Say in the case of music through artists, songs, albums, genres etc.

[fms]

I can't really understand how you can read my sentence of "The File manager UI optimizes for file management tasks" into "Are you telling me that the File Manager is not an optimal UI for managing files?"
This is not the sentence I have been commenting on. I have been commenting on your insistence that one should not use the File Manager to manage media files. This sounded rather silly to me, as there is no principal difference between media files and other files.

No, we're not saying that. File manager is specifically optimized for managing files.
Apparently not. If you compare Maemo File Manager with any other popular file manager (starting with the Windows Explorer, for example), you will immediately see that:

1. Maemo File Manager does not make good use of screen estate by showing just a few files and obscuring long file name from the user.
2. Maemo File Manager cannot handle directories containing a lot of files (it becomes unusably slow on them, and eventually crashes, I think).

These two issues have to be fixed before you can say that Maemo File Manager is optimized for managing files. Same issues have to be fixed in the standard file selector.

What we're saying is that managing files != consuming files. File management is for copying/moving/sorting/creating folders etc., consumption is for browsing, filtering, consuming etc. The optimal UI's for those two streams of tasks are different.
Absolutely correct, although I would still expect to be able to "consume" a file by clicking on it in the file manager. But, as I described above, "consuming" files is not the problem. The problem is that the File Manager fails at managing files.

[ragnar]

So, yes, I can abandon all the apps Nokia ships with the device and use third-party ones. But this will mean that Nokia utterly failed in delivering a device that is usable out-of-the-box. When you ship a device, you have to ship it with apps that actually work and are comfortable to use. Instead, you seem to choose a really small number of artificially created "use cases" and tell everyone not fitting them to just bug off. Don't you think it is wrong?

Obviously that is not our goal.

Then again, not every use case that every person happens to mention will automatically get accepted into the list of implementable features.

[fms]

Obviously that is not our goal. Then again, not every use case that every person happens to mention will automatically get accepted into the list of implementable features.
But I hope you do agree that these are valid use cases that pretty much have to be accepted:

1. Managing files (variable number of files of variable size, including large files and directories with a lot of files)
2. Playing games (including 3D games and fast paced games with directional controls)
3. Reading books and other documents
4. Consulting maps

I am kinda concerned about three use cases appear becoming abandoned in the upcoming Fremantle device at the moment. And to me, they do not look like unreasonable scenarios only encountered by geek weirdos.

Please notice that #3 and #4 basically benefit from retaining largish screen size, so they are more on the hardware side. #2 needs both physical directional controls and reasonable 3D APIs for apps (in an exclusive full-screen mode, if required by hildon-desktop specifics). #1 just needs somebody to sit down and fix that damn file manager, and the file selector as well. Preferably, this has to be some guy who uses file managers and knows what they should look like.

[ragnar]

But I hope you do agree that these are valid use cases that pretty much have to be accepted:

1. Managing files (variable number of files of variable size, including large files and directories with a lot of files)
2. Playing games (including 3D games and fast paced games with directional controls)
3. Reading books and other documents
4. Consulting maps

I am kinda concerned about three use cases appear becoming abandoned in the upcoming Fremantle device at the moment. .

Please notice that #3 and #4 basically benefit from retaining largish screen size, so they are more on the hardware side. #2 needs both physical directional controls and reasonable 3D APIs for apps (in an exclusive full-screen mode, if required by hildon-desktop specifics). #1 just needs somebody to sit down and fix that damn file manager, and the file selector as well. Preferably, this has to be some guy who uses file managers and knows what they should look like.

1) Yes, to some extent. Ultimately we are perhaps more focusing on users dumping files on the devices and then accessing them through Tracker than having to "go on managing" them all the time. I don't think that managing is a satisfying or fulfilling use case, consuming them is. Fire and forget is a much better approach, imho. And there's also the PC side there. Explorer or Finder is a really good management UI, so leveraging that when possible isn't a bad thing.
2) Yes, to some extent. No, it's not a PSP or a Nintendo DS. Just the hardware doesn't make something a good gaming device (just ask the Gizmondo guys, for instance. :)

It's a chicken and egg -problem: I personally don't know of a massive library of great games available for the N810. From my personal viewpoint I think that on touch screen devices the best games are utilizing the touch screen. Playing Tux (or what was the penguin game) on the Nokia 770 was quite painful with its hardware rocker.
3) Certainly.
4) Certainly.

[fms]

1) Yes, to some extent. Ultimately we are perhaps more focusing on users dumping files on the devices and then accessing them through Tracker than having to "go on managing" them all the time. I don't think that managing is a satisfying or fulfilling use case, consuming them is.
That is obviously a misconception. It is almost like you want your users to eat food but do not want them to prepare it. This may work for iPhone, with its iTunes store and an audience of users willing to put up with whatever Apple inflicts on them. This is not going to work for Maemo, starting with the fact that Nokia does not provide anything comparable to iTunes in functionality and ending with the Maemo user base not willing to put up with the lack of control of their data. This means that users will manage their own media files and you have to address this activity properly.

2) Yes, to some extent. No, it's not a PSP or a Nintendo DS. Just the hardware doesn't make something a good gaming device (just ask the Gizmondo guys, for instance. :)
Ok, not talking about specialized gaming devices here. But let us take pretty modest games available on Nokia devices via NGage. A lot of them (if not most) require directional controls and OpenGL ES APIs to be usable. I hope we both agree that having at least this kind of games play is well within the intended use for Maemo?

It's a chicken and egg -problem: I personally don't know of a massive library of great games available for the N810.
Oh, I do ;)

[sachin007]

1) Yes, to some extent. Ultimately we are perhaps more focusing on users dumping files on the devices and then accessing them through Tracker than having to "go on managing" them all the time. I don't think that managing is a satisfying or fulfilling use case, consuming them is. Fire and forget is a much better approach, imho. And there's also the PC side there. Explorer or Finder is a really good management UI, so leveraging that when possible isn't a bad thing.
2) Yes, to some extent. No, it's not a PSP or a Nintendo DS. Just the hardware doesn't make something a good gaming device (just ask the Gizmondo guys, for instance. :)

It's a chicken and egg -problem: I personally don't know of a massive library of great games available for the N810. From my personal viewpoint I think that on touch screen devices the best games are utilizing the touch screen. Playing Tux (or what was the penguin game) on the Nokia 770 was quite painful with its hardware rocker.
3) Certainly.
4) Certainly.

The shift from tablets to iclones has been complete.

All the things that made the tablet series laptop replacements are being left out. I have no hope left for any nokia tablets. It is time to jump ship.... even though it really hurts me.

[fms]

The shift from tablets to iclones has been complete. All the things that made the tablet series laptop replacements are being left out. I have no hope left for any nokia tablets. It is time to jump ship.... even though it really hurts me.
Rather than jump ship, I would suggest to continue explaining to Nokia marketing guys, in polite logical terms, just what we want from Maemo devices as users. My hope is that the Maemo marketing team will see the light and make those few widely requested changes to get things back on track. After all, there is just a few (3-4) changes people request and all of them (except for the screen size, I guess) can be satisfied rather cheaply.

[Bobbe]

The shift from tablets to iclones has been complete.

All the things that made the tablet series laptop replacements are being left out. I have no hope left for any nokia tablets. It is time to jump ship.... even though it really hurts me.

Er... why? Maybe I'm missing something, but we are here discussing SOME user cases the next tablet / OS should focus on. Nobody is restricting usability scenarios to those cases. (Right?)

But I do wonder, what are we leaving out here? This is not a comprehensive list, but should it be?

If we want to discuss other things that the Fremantle release should address in order to keep it a umpc, what should those be? (I ask genuinely, no snide remark intended). MS Office filetype support is an issue for sure, let's face it, Google Docs doesn't cut it, but I don't think that what the Nokia guys are saying here is that they won't focus on it. Unless I missed something.

But then again, this may be the subject for another thread. Aren't we talking at cross purposes here?

[sachin007]

Rather than jump ship, I would suggest to continue explaining to Nokia marketing guys, in polite logical terms, just what we want from Maemo devices as users. My hope is that the Maemo marketing team will see the light and make those few widely requested changes to get things back on track. After all, there is just a few (3-4) changes people request and all of them (except for the screen size, I guess) can be satisfied rather cheaply.

I guess it is better to do it now than later being told that "Multiple apps drain battery and cpu.. so we are limiting the no. of open apps at a time to 1. After all this is a mobile device and we cant satisfy some very rare use case scenario."

[TA-t3]

My N800 is a small pocketable computer and that is why I am an N800 owner. It doesn't have a specific, limited use case. This is the shortest possible message I can think of, for Nokia.

[Bobbe]

My N800 is a small pocketable computer and that is why I am an N800 owner. It doesn't have a specific, limited use case. This is the shortest possible message I can think of, for Nokia.

This is how I think of it too, but I think that is a use case, isn't it?

As a user of a small pocketable computer you have very specific needs that some users won't. And yet you persist as being a niche. And a very good one, if Nokia knows how to please you. Because the moment it delivers you a small pocketable computer experience out of the box that you're satisfied with, it will have a device ready to take over huge market niches that are currently in doubt between netbooks, umpcs and so on so forth.

So if I were Nokia, I'd be listening to you just as carefully as I would be listening to the Iphonesque-features-have-to-be-there choir.

Now try and please them both.

One of the cool things about being a mammoth as big as Nokia is that they're one of the few companies in the world who can, if they apply their resources correctly and cooperate with the community accordingly. Honestly, I've seen them doing both (Quim and Rainar are here to prove that every single day), and not doing them as well. Let's see what happens from now on.

Alea Jacta Est.

(And a sincere good luck to Nokia. A ferociously eager community like this to take on (and don't even think of not trying to understand what these guys want, it will be your doom :p) and a lot of consumer minds to read on the other end at the same time. Honestly, good luck :D)

[javispedro]

On the other side, the reason I chose the N810 over the Pandora and other Linux based MIDs is that, while having a full computer's power available, there was still a nice handheld GUI with instant-on (instant-resume here ;) ) and everything I would expect from a handheld GUI (including, but not limited to, big task switching buttons, fullscreen applications, fast-launching key applications, etc.).

So there must be some balance.

Other than that you know I still believe Fremantle seems too much dumbed-down. Hope to be proven wrong, or that "the usability improvements" are really that good.

[ragnar]

Rather than jump ship, I would suggest to continue explaining to Nokia marketing guys, in polite logical terms, just what we want from Maemo devices as users. My hope is that the Maemo marketing team will see the light and make those few widely requested changes to get things back on track. After all, there is just a few (3-4) changes people request and all of them (except for the screen size, I guess) can be satisfied rather cheaply.

Sorry for possibly repeating stuff, but could you list those changes once again?

[Master of Gizmo]

Have you used such Help in Maemo applications? I know I haven't.


Sure, for example in Maemo Mapper. And when i asked for the help system the reply was not "we don't think they are needed". The reply was "we don't provide a framework anymore, so you'll have to come up with your own solution".


In terms of text selection, Modest is more an exception than a norm because it still uses gtkhtml. So please don't make conclusions for the whole platform based on it.


But these are the examples visible today. And it's funny that you mention modest to use gtkhtml as i have been told not to use gtkhtml as it isn't supported anymore and doesn't work nicely with the hildon pannable area.


Let's discuss examples of real applications, please. In which ones do you expect selecting text is going to be a problem?


GpxView displays geocache descriptions in a gtkhtml view (if they are in html format) or a gtktextview (if they are plain text). It's a typical use case to copy formulas (like "You see A trees and B steps, so go 3*(A+B) meters north") into the notes view and work with them there.

I have a general problem with the direction of the changes. On one hand you say it's a device for hackers and Linux geeks. And i agree as those people who just want a small sexy device will prefer an iphone or similar as it's designed to be sexy instead of open. The average user imho doesn't care for openess. So fremantle is addressing the hacker and geek, true?. Why do you then simplify the interface so much? Hackers usually prefer capabilities over simplicity. So what's the target audience of fremantle? Hackers? Average users? My Mom? Former IPhone owners? I am a little confused ...

[BrentDC]

what?!?!?!

i cannot believe all this. i wish i'd never looked at this thread. :(

Just in X-Term, though, right? There is no autocomplete in X-Term now...

[ragnar]

That is obviously a misconception. It is almost like you want your users to eat food but do not want them to prepare it. This may work for iPhone, with its iTunes store and an audience of users willing to put up with whatever Apple inflicts on them. This is not going to work for Maemo, starting with the fact that Nokia does not provide anything comparable to iTunes in functionality and ending with the Maemo user base not willing to put up with the lack of control of their data. This means that users will manage their own media files and you have to address this activity properly.


Well, I think it is somewhat derogatory to talk about Apple audiences and "Maemo user bases" like that. Obviously we want to expand any current user bases to a great extent, therefore I wouldn't make generalized statements like that: the intended user base is not dramatically different from any other user base.

And I therefore wouldn't agree with your statement. People want to have a good experience with consuming and interacting with their data. I don't think most Apple users miss terribly "lack of control" with their data. As long as the overall experience has no gaps, I would claim most people prefer the simpler approach. Then again, I'm not saying that we would going the Apple route.


Ok, not talking about specialized gaming devices here. But let us take pretty modest games available on Nokia devices via NGage. A lot of them (if not most) require directional controls and OpenGL ES APIs to be usable. I hope we both agree that having at least this kind of games play is well within the intended use for Maemo?


I'm not that familiar with the NGage offering, it's a whole different unit. I am under the impression that games are Symbian or Maemo specific, so I wouldn't be talking about cross-platform support. (But I could be off on this subject.)

I.e. I don't know of a wide pool of games that we could be automatically supporting but we would be not even though we wouldn't have those two features. (That is not to say if they are there or not.)

I know that the iPhone has turned out to be a very successful gaming platform, despite not being particularly targeted towards gaming. They have sufficient enablers in the HW and SW side for games development, plus most importantly now a sufficiently large user base for commercial development. But it's just an example to say that there are other ways to do good gaming devices than just sticking directional controls and support to any certain technology.

[BrentDC]

Hi, wouldn't it be better to have separate threads to discuss different topics?

I'm only speaking as a Maemo & Fremantle user here.



Have you used such Help in Maemo applications? I know I haven't. Even in my full GNOME desktop I have used the Help system only in few occasions after several years. The apps I use in Maemo tend to be self-explanatory. If I have questions I find the answers online.

What are your experiences with Help systems in mobile devices?

What is wrong with the Help system now? Yes I realize that not many developers use it, but that is not because of the system, but because of the developers developing for the platform.

One-man Open Source developers were never known to write help documents ;)

But isn't Fremantle supposed to be a mass-market device? And mass-market = commercial developers. And we all know commercial developers write very nice help systems. Look at Digia@scene or @Web, both utilize the help framework and provide very nice help documents. Digia is one of the few commercial developers developing for the platform now and they utilize the help system very well.

What are the thousands of commercial developers going to do with Fremantle? Are you saying Nokia doesn't want commercial developers and wants to keep Maemo a hobbyists toy? No? If not, why remove the help system right before it is going to be used as it was designed to be?

Also, my application uses the Help.


In terms of text selection, Modest is more an exception than a norm because it still uses gtkhtml. So please don't make conclusions for the whole platform based on it.

Let's see this from a user point of view:

- The Maemo selecting behavior up to Diablo could be improved specially in scrollable areas, according to many sources e.g. this old bug (https://bugs.maemo.org/show_bug.cgi?id=166). This justifies the action to change things in Fremantle, where scrolling and panning has a more important role.

- The Maemo browser has a specific gesture to activate text selection. Any application using the browser engine to render its own content can benefit from its gestures at will, including text selection.

- Text selection is not an issue in non-scrolling/panning areas. Developers can offer an interface where the user just needs to move his finger from beginning to end of the text selected.

What cases fall out of these two categories? Developers can still offer the change from pannable to selectable areas in one click. The assumption is that this separation will make life of users easier than in Diablo and previous versions.

Where is the API document describing this property? I've looked everywhere, yet haven't found this documented in either hildon.PannableArea or hildon.TextView (my application, a text viewer, is an exception to the above rules I guess).

Thanks.


Let's discuss examples of real applications, please. In which ones do you expect selecting text is going to be a problem?

Quick Clip (the viewer part) for one.

[conny]

Where is the API document describing this property? I've looked everywhere, yet haven't found this documented in either hildon.PannableArea or hildon.TextView (my application, a text viewer, is an exception to the above rules I guess).

That's true. And even if there would be API documentation about that it's still completely undefined how the switching between selection-mode and panning-mode should be exposed to the user.
I asked how the default web browser will do it and was told it is a surprise :eek:
Have a look at the last 3 comments here: https://bugs.maemo.org/show_bug.cgi?id=166

[fms]

I guess it is better to do it now than later being told that "Multiple apps drain battery and cpu.. so we are limiting the no. of open apps at a time to 1. After all this is a mobile device and we cant satisfy some very rare use case scenario."
This is technically incorrect. You have only one CPU, so at most one app is running at each moment of time. And most of the time, no apps are running, as they are all waiting for the user input.

[fms]

Sorry for possibly repeating stuff, but could you list those changes once again?
On the software side:

1. Fix Modest to work properly, every time, in every setting (IMAP or POP), with any connection (even if it regularly breaks during background mail check).
2. Redesign layout of File Manager and file selector to show more files at once and show as much of a file name as the screen width allows.
3. Fix File Manager and file selector to work with large directories, possibly add rudimentary sorting abilities for easier access (by-name, by-type, by-date, by-size).
4. Make all basic widgets (and the desktop, preferably) work properly in portrait screen mode. No need to make all bundled apps work in portrait mode, as it will take too much resources.
5. Make it possible for applications to use OpenGL ES APIs. The easiest way it can be done is to implement the exclusive full screen mode which gives application full control of the frame buffer and the 3D context. See how it is done in DirectDraw/Direct3D (Windows) and SDL (Linux).
6. Fix browser so that multiple Flash objects do not hang the tablet. Yes, I know that Adobe is to blame, but this can be worked around by not letting plugin instances take too much CPU.
7. Modify XTerm with the latest patches, including full-screen overlay keyboard.

More difficult stuff:
1. Add a decent dpad. "Decent" means large, easy to operate quickly. One way to do it would be to place four round buttons in a cross-like formation at the back of the device, opposite to the camera. The same pad can be used to operate the camera. (it is a hardware request, I know, the only reason why it is here is because it is important).
2. Bring back virtual input methods. A lot of people find it easier to use virtual keyboard.

These are the issues I have seen people discuss lately. There may be some others as well.

[fms]

And I therefore wouldn't agree with your statement. People want to have a good experience with consuming and interacting with their data. I don't think most Apple users miss terribly "lack of control" with their data. As long as the overall experience has no gaps, I would claim most people prefer the simpler approach. Then again, I'm not saying that we would going the Apple route.
The point was not to claim that iPhone users are somehow inferior to Maemo users. The point was to remind that before you start "consuming content", you usually have to manage it. iPhone users manage their content with iTunes, tightly integrated with their hardware. Maemo does not have a similar tool, and even if Nokia makes it, I have strong doubts anybody will use it, based on my experience with previous desktop offering from Nokia.

I'm not that familiar with the NGage offering, it's a whole different unit. I am under the impression that games are Symbian or Maemo specific, so I wouldn't be talking about cross-platform support. (But I could be off on this subject.)
The NGage has been used as an example of games a Nokia mobile device user would play on his Maemo device. These are simple games, not trying to measure up to PSP or DSi by any means. But they still require a dpad, most of the time. And yes, many of them make use of the OpenGL ES.

I.e. I don't know of a wide pool of games that we could be automatically supporting but we would be not even though we wouldn't have those two features. (That is not to say if they are there or not.)
A few examples: Quake, Doom, Bomberman, XKobo, and a few hundreds emulated games from other platforms.

I know that the iPhone has turned out to be a very successful gaming platform, despite not being particularly targeted towards gaming. They have sufficient enablers in the HW and SW side for games development, plus most importantly now a sufficiently large user base for commercial development.
Well, Maemo is not iPhone, so you cannot hope that thousands of developer will suddenly start writing games for it. Instead, you can make use of the existing games, both JavaME-based (from NGage and other mobile stores) and emulated (from older gaming consoles), but you still have to have a dpad for that. No dpad - no deal.

[fms]

2. Bring back virtual input methods. A lot of people find it easier to use virtual keyboard.
Little clarification on this:
If I understand things correctly, the main obstacle to this is the need to make all applications resize properly when the virtual keyboard is shown. Given that the new Maemo device is supposed to have hardware graphics acceleration, the virtual keyboard can be made semi-transparent (with configurable opacity) and overlaid onto the normal screen. Advantages of this method:

1. You do not need to fix all the apps to work in that cramped half-screen layout with virtual keyboard taking the bottom of the screen.
2. The applications can use the whole screen even with virtual keyboard present.
3. The virtual keyboard always takes the whole screen so it may have more buttons and be finger operated.

[qole]

I asked how the default web browser will do it and was told it is a surprise :eek:

I think Maemo don't want third party developers stealing their coolest ideas. You can have them when everyone else does, not before!


5. Make it possible for applications to use OpenGL ES APIs. The easiest way it can be done is to implement the exclusive full screen mode which gives application full control of the frame buffer and the 3D context. See how it is done in DirectDraw/Direct3D (Windows) and SDL (Linux).

I think an SDL library (http://www.gp32x.com/board/index.php?showtopic=48023) would probably do the trick. I don't think many game developers / porters would be upset if they were told to use SDL.

No, you have two Nokia employees that are spending a big chunk of their busy morning trying you to explain why things are designed and implemented the way they are.

Having watched this pattern repeat itself in the forums and on the mailing lists, I'd like to suggest that Nokia employees don't waste "busy morning" time defending current policy or decisions. It doesn't seem to move the conversation forward, it often doesn't placate the complainers, and it often just adds fuel to the fire and spawns a long argument that doesn't lead anywhere new.

Focus on the stuff that you believe is valid and can be changed; don't waste time arguing about things that aren't a priority for Maemo or Nokia.

This only applies to when you're wearing your Nokia hats. Feel free to argue about anything you want as community members. The problem is that posts from ragnar, qgil or Peter@Maemo Marketing (among others) will rarely or never be interpreted as community member posts.

[nilchak]

As much as we expect these companies to play ball with the community and keep a healthy score and be open, its has to work both ways.

I.e. sometimes the community members have to realize that corporations are not community like and they have t function with profit motives in mind, with a central directive from some departments etc. Hence in design decisions, we have to cut some slack as well and not just "expect" things from the corporation entity to be "our" way.

That's the whole give-and-take of this new relationship - of a corporation and a community.

As for the issues and what I underastand
I am ok personally with some of the taking away of functions and changing things to suit the finger-frindliness of the UI.
But again basic things like cut-n-paste and file explorer with enough of file details etc are essential to making it a powerful device.

And I understand Nokia has some tricks up its sleeve, but at least let us know we will have this and we will not have that - instead of this cat and mouse game of trying to second-guess which features are missing.

And all kudos to QGil and Ragner for their communication.
Just don't shoot the messenger is all.

On the issues

Help :
----------
was not used much and I don't feel I will miss a central help system as much. In fact most apps can just have an online help with a link in the application.

Cut-n-paste functionality -
--------------------------------------
Very much needed.
Some apps in mind : Yellow Notes - i keep notes in that and need to copy-paster into tidbits (like email id) to other apps.

Notes application - same as above.

Contact app - like to copy a contact detail to paste in some other app or vice-versa.

And lastly from the browser - which I gather there is a method (a hidden one at that)


DPad -
-----------
for scrolling at least - cant always use finger scrolling for a long text document say ... thats tiresome.
also for Games as others mentioned.


Rotation :
--------------
I would expect a modern day platform to support rotation in both landscape and portrait quite frankly. There are many time I just want to read something in portrait mode - and this should be a device platform specific function - not an application specific.
Whats the use of that accelerometer if not for rotation ?

The Zaurus with Qt did rotation pretty well (had its defects as well) but it applied that to all apps and Qt layouts (if properly done) supported resizing and replacement of controls nicely too.

So biq question - will Harmattan which is supposed to have Qt built in support better rotation ?

[luca]

I think Maemo don't want third party developers stealing their coolest ideas. You can have them when everyone else does, not before!
I really don't care if it is a surprise or not, what irritates me is that it is the cause we don't have any update to the broken browser in diablo.
Luckily, thanks to tear, I've no need for the supplied browser (in fact, among the supplied programs, I just use the rss reader, and it's as broken as the rest of the bunch. If I only could remove all of them and free up some of the flash memory I'd be happy).

[Kozzi]

Please reconsider portrait mode for maemo devices. I'm not programmer or anything regarding software development so I don't know how difficult it is, but maemo 5 device as a phone and operatable only in landscape is ... disappointing.

[conny]

Please reconsider portrait mode for maemo devices. I'm not programmer or anything regarding software development so I don't know how difficult it is, but maemo 5 device as a phone and operatable only in landscape is ... disappointing.
Portrait mode is possible. It's just harder to use (as a developer) as it should be. IMHO ;) But there will be applications supporting it.

[Architengi]

Cut-n-paste functionality -
--------------------------------------
Very much needed.


DPad -
-----------
for scrolling at least - cant always use finger scrolling for a long text document say ... thats tiresome.
also for Games as others mentioned.


Rotation :
--------------
I would expect a modern day platform to support rotation in both landscape and portrait quite frankly. There are many time I just want to read something in portrait mode - and this should be a device platform specific function - not an application specific.
Whats the use of that accelerometer if not for rotation ?

So biq question - will Harmattan which is supposed to have Qt built in support better rotation ?

It is dishearting to see how Nokia stumbles in its strategy. If they cannot support rotation on the OS, get a life guys. Take a break!
You had 2 years since the last Maemo device was launched (N810) and 2 years from when the iPhone was launched to learn and do things.
I told them, get some Russian or Romanian programmers, they are good and fast, or get some US or Israeli programmers (but they are 10x more expensive). From my experience forget about India or you have to baby step them with every small instruction.

If Nokia cannot get rotation and copy-paste at OS level, they can have a break, enjoy French riviera, come back and use Android. Forget about Symbian or Maemo, if they are always behind the rest of the OSes. Nokia cannot deliver anymore, they are stuck with burreucracy and the wrong vision.

OS version update (over the network/air)
-----------------------

OS update, Nokia does not support OS version update. This makes life hard for everybody, for programmers to support Symbian v3, v3-fp1, v3-fp2, v5, for Nokia to support all these version on the systems, and even worst they play and dance after the operator music. This is not possible any longer, there are too many combination of operators/countries/version of OSes possible that makes everything so slow. This is why ovi store took taht long, to accustomize it to every market, operator, OS version, phone model, etc. Too much burreacracy at Nokia, too many standards. Try to force OS update (like Microsoft forces its patches over the network, and how Apple give for free to old iPhone users the new OS v3), and have a unified OS. Use Symbian v5 even for non touch devices, without the touch. Use one OS version for Symbian, one OS version for Maemo, and get rid of the s40. But hurry up, before the boat sinks completely. ;)

[Jaffa]

If Nokia cannot get rotation and copy-paste at OS level

Copy & paste and rotation are at OS level in Fremantle. This is a thread about issues with the APIs and how to give the user the best experience when other people write Maemo 5 applications; not the user land applications which ship with Rover.

OS update, Nokia does not support OS version update.

Except Maemo does, so this stuff about Symbian is off-topic and irrelevant ;-)

[qviri]

I think Maemo don't want third party developers stealing their coolest ideas. You can have them when everyone else does, not before!

Because we've all seen how badly cool third-party application turned out for a fruit-themed company.

[Architengi]

Copy & paste and rotation are at OS level in Fremantle. This is a thread about issues with the APIs and how to give the user the best experience when other people write Maemo 5 applications; not the user land applications which ship with Rover.



The API is part of the OS. If the published API does not have functions for some things, how can the applications access that OS functionality?
I am not talking about a "secret" or internal API used by the core team of Maemo. The published API needs to have those functions.
The same with hardware - D-pad needs to be there. I would say multi-touch as well.

[BrentDC]

The API is part of the OS. If the published API does not have functions for some things, how can the applications access that OS functionality?

Rotation is covered in the API, and although I haven't looked into it yet, I think all the developer needs to do is set a "my application can rotate" property and then the OS will let the user rotate the application.

How well the Hildon and GTK widgets resize after rotation is another story entirely...


I am not talking about a "secret" or internal API used by the core team of Maemo. The published API needs to have those functions.
The same with hardware - D-pad needs to be there. I would say multi-touch as well.

Text-selection appears to be, as conny said, a secret.

[Jaffa]

Rotation is covered in the API, and although I haven't looked into it yet, I think all the developer needs to do is set a "my application can rotate" property and then the OS will let the user rotate the application.

That's my reading of the API docs, but I've not tested it. Seems like conny has, though :-)

How well the Hildon and GTK widgets resize after rotation is another story entirely...

Indeed.

Text-selection appears to be, as conny said, a secret.

I'd say "undocumented" (ragnar's comment notwithstanding) rather than "secret". Let's see what happens with #4619 (https://bugs.maemo.org/show_bug.cgi?id=4619) over the next few days :-/

[BrentDC]

I'd say "undocumented" (ragnar's comment notwithstanding) rather than "secret". Let's see what happens with #4619 (https://bugs.maemo.org/show_bug.cgi?id=4619) over the next few days :-/

Woo-Hoo! That bug is up to 13 votes, that should get Nokia's attention.

Complaining on the forums (http://talk.maemo.org/showpost.php?p=295053&postcount=3) works every time ;)

[YoDude]

-The Maemo browser has a specific gesture to activate text selection. Any application using the browser engine to render its own content can benefit from its gestures at will, including text selection.

I like that^ a lot... How many gestures? (If you can answer at this time. :) )

[gtallan]

What is wrong with the Help system now? Yes I realize that not many developers use it, but that is not because of the system, but because of the developers developing for the platform.


To be honest, for the built-in apps the problem with the Help system is that the help is too superficial. It should be improved, not abandoned.

If I cast my mind back to my old Psion netbook, I DID use the help in that, because it really documented how to use the applications properly.

Graham

[tso]

i guess the issue there is one of writing documentation rather then code...

[conny]

Just to make it clear again. There is support for portrait mode in Fremantle and it is possible for everyone to use it.

My point was that it should be easier for developers to use it and that there are some bugs that should get fixed.

To review the whole process I made Conboy (http://talk.maemo.org/showthread.php?t=28355) orientation aware yesterday. In the attached screenshot you can see the note selection / search window.

When in landscape mode, it will show two columns + a text field for searching. When rotated into portrait mode it will show only one column (because of space) and no search field (because (probably) not keyboard).

[qgil]

For the search, note that if you would have it in portrait mode then a portrait virtual keyboard would be also needed, and Maemo 5 doesn't come with that. But wait, note taking app in portrait mode without portrait keyboard?

So you start seeing that anyway Conboy fully working in portrait mode is more complex than just fine tuning a couple of widgets.

[fms]

For the search, note that if you would have it in portrait mode then a portrait virtual keyboard would be also needed, and Maemo 5 doesn't come with that. But wait, note taking app in portrait mode without portrait keyboard?
Check above in this thread for a request to reenable virtual input methods in Fremantle and a suggestion how this can be done without having to resize applications.

[conny]

For the search, note that if you would have it in portrait mode then a portrait virtual keyboard would be also needed, and Maemo 5 doesn't come with that. But wait, note taking app in portrait mode without portrait keyboard?
Ähh?! I was writing exactly that. I removed the search field because there is no portrait keyboard.
For the rest of the application a note taking application has at least two use cases:
Writing and reading.
Reading notes is perfectly possible without having a keyboard. And also deleting notes would be possible if the confirmation dialog wouldn´t get crippled.

So you start seeing that anyway Conboy fully working in portrait mode is more complex than just fine tuning a couple of widgets.
I requote myself "My point was that it should be easier for developers to use it and that there are some bugs that should get fixed."

[GeneralAntilles]

Check above in this thread for a request to reenable virtual input methods in Fremantle and a suggestion how this can be done without having to resize applications.

At least be clear. You make it sound like there are no virtual input methods in Fremantle (which is clearly not the case) when it was only the stylus keyboard which was dropped.

[fms]

At least be clear. You make it sound like there are no virtual input methods in Fremantle (which is clearly not the case) when it was only the stylus keyboard which was dropped.
Ok, to generalize, there should be an input method that lets you enter text without obscuring the application display. A semi-transparent full-screen keyboard should suffice (see somewhat ugly implementation for XTerm that can be refined for a general case).

[Andre Klapper]

Here's another one - https://bugs.maemo.org/show_bug.cgi?id=4618

I remember getting pissed off at Nokia because they wouldn't include the rotation patch into the Diablo kernel and xserver. But it would be a supported mode in Fremantle and that was, er, the end of that bug. Now, the bug above points out something wrong with the way Nokia's doing this implementation and it's a WONTFIX. The WONTFIX issue never bothered me before (say, except for the diablo rotation bug) but if Nokia are already giving out the WONTFIXes - for legit bugs - in their new OS, then they can **** off.

I currently see two areas of big frustration for 3rd party developers: Theming not working for some widgets because of widget functionality that was never tested/covered by official Nokia applications, plus the portrait mode mentioned here.
For both issues several bug reports exist in maemo.org Bugzilla.
Feel free to vote for them.

Of course the best solution would be if Nokia covered every possible setting of any widget, but I guess that's quite unrealistic and costs a lot of time and money.
So at least the documentation should be TOTALLY CLEAR about what is supported and what is not.
And as far as I see this is what Nokia is currently made aware of and also gets discussed internally within Nokia - so it's quite good that people in the maemo.org community made some noise about this, but keep it constructive. :-)

[Andre Klapper]

Not to mention that currently filling the (JFFS2) root filesystem eats up RAM as well.

According to https://bugs.maemo.org/show_bug.cgi?id=2615#c73 JFFS2 is not used in Fremantle anymore.

[lma]

According to https://bugs.maemo.org/show_bug.cgi?id=2615#c73 JFFS2 is not used in Fremantle anymore.

Yeah, that's why I specified it explicitly ;-) I understand Fremantle will use UBIFS (http://www.linux-mtd.infradead.org/doc/ubifs.html) for the root filesystem, and that doesn't suffer from this issue.

[javispedro]

Yeah, that's why I specified it explicitly ;-) I understand Fremantle will use UBIFS (http://www.linux-mtd.infradead.org/doc/ubifs.html) for the root filesystem, and that doesn't suffer from this issue.

Is that true? I thought it would use plain ext2 over a block device (à la Palm Pre).

[GeneralAntilles]

Is that true? I thought it would use plain ext2 over a block device (à la Palm Pre).

Yes, it's true. Check the kernel changelog.

[attila77]

Since the filemanager discussion was in this thread I thought it would be interesting to link back for people who might not read maemo news...

http://tabletui.wordpress.com/2009/06/10/fremantle-ui-file-chooser/

So there *is* some additional magic going on, but we have yet to see how well it does in real life :)

[lma]

Is that true? I thought it would use plain ext2 over a block device (à la Palm Pre).

As far as we know (http://lists.maemo.org/pipermail/maemo-community/2009-April/002226.html)... The relevant parts of the Fremantle beta kernel rx51_defconfig are:
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_WL_THRESHOLD=4096
CONFIG_MTD_UBI_BEB_RESERVE=1
CONFIG_UBIFS_FS=y
CONFIG_UBIFS_FS_LZO=y
CONFIG_UBIFS_FS_ZLIB=y
CONFIG_EXT2_FS=m
CONFIG_EXT3_FS=m

Which means the kernel can't mount an ext2/ext2 root filesystem (there's no initfs (https://bugs.maemo.org/show_bug.cgi?id=3745#c2) either in Fremantle).

Keep in mind also that ext2 & family (especially the journaled versions!) are not very well suited for a raw flash device (SD cards that do their own wear leveling are a different story). The UBIFS (http://www.linux-mtd.infradead.org/doc/ubifs.html) page has a lot more info than you probably ever wanted to know on the subject ;-)

Oh, and I should add UBIFS was developed by Nokia.

[GeneralAntilles]

So there *is* some additional magic going on, but we have yet to see how well it does in real life :)

Just to be clear, wazd is in no way associated with Nokia or Maemo Devices.

[qgil]

Portrait mode in Conboy focusing on reading notes? Alright, makes sense. In such case portrait mode is probably associated with one hand usage / on the go. What about offering the notes sorted by last edited with a visible button offering to change view to last opened sorting? This would most probably satisfy use cases like shopping list, speeches, memos, classroom notes... Probably better than defaulting to alphabetical sorting.

Probably that makes sense for landscape too?

[qole]

Just to be clear, wazd is in no way associated with Nokia or Maemo Devices.

That's right. He works for Mer Devices. ;)

[kanishou]

JTo review the whole process I made Conboy (http://talk.maemo.org/showthread.php?t=28355) orientation aware yesterday. In the attached screenshot you can see the note selection / search window.


This looks good so far, just two quick notes:

- Try using hildon entry placeholder text instead of the "Search:" label. It usually looks cleaner and is meant for this purpose.

- The underline for the "_Clear" button is not really needed, it just adds visual clutter on a touchscreen device.

[conny]

Portrait mode in Conboy focusing on reading notes? Alright, makes sense. In such case portrait mode is probably associated with one hand usage / on the go.
Exactly!

What about offering the notes sorted by last edited with a visible button offering to change view to last opened sorting? This would most probably satisfy use cases like shopping list, speeches, memos, classroom notes... Probably better than defaulting to alphabetical sorting.

Probably that makes sense for landscape too?
The default sorting for both portrait and landscape mode is already "sort by date" which results in showing the last edited notes at the top of the list. The user can tap the title bar to open the window menu. There he can switch between "sort by title" and "sort by date".

[...] with a visible button offering to change view to last opened sorting [...]
I'm not sure what you mean by that. Could you elaborate please?

[conny]

This looks good so far, just two quick notes:

- Try using hildon entry placeholder text instead of the "Search:" label. It usually looks cleaner and is meant for this purpose.

- The underline for the "_Clear" button is not really needed, it just adds visual clutter on a touchscreen device.

Thanks for the input! I'll try the hildon entry placeholder thing.
Regarding the "_Clear" button: It's a stock button (GTK_STOCK_CLEAR). So maybe Hildon should generally suppress mnemonics on stock items?!

[conny]

- Try using hildon entry placeholder text instead of the "Search:" label. It usually looks cleaner and is meant for this purpose.

I tried it now but it doesn't really make sense.
The thing is, the search text entry field always has the focus. But as soon as a HildonEntry widget has the focus the placeholder text is not shown anymore. So in my case the placeholder text is only shown while panning the list, because this is the only situation that the HildonEntry does not have the focus....

[kanishou]

Thanks for the input! I'll try the hildon entry placeholder thing.
Regarding the "_Clear" button: It's a stock button (GTK_STOCK_CLEAR). So maybe Hildon should generally suppress mnemonics on stock items?!

Right, those should be disabled in the SDK. I will have a look at this.

But there is another problem with using a stock button, in that it doesn't adopt the right themeing by default. I would suggest to use hildon_button_new (HILDON_SIZE_FINGER_HEIGHT, ..) (or hildon_gtk_button_new), but if you want to keep using the stock ID, then you should manually call hildon_gtk_widget_set_theme_size() after creating the button.

[conny]

Right, those should be disabled in the SDK. I will have a look at this.
That's nice! Thanks :)

But there is another problem with using a stock button, in that it doesn't adopt the right themeing by default. I would suggest to use hildon_button_new (HILDON_SIZE_FINGER_HEIGHT, ..) (or hildon_gtk_button_new), but if you want to keep using the stock ID, then you should manually call hildon_gtk_widget_set_theme_size() after creating the button.
I just tested that and in my case calling hildon_gtk_widget_set_theme_size(button, HILDON_SIZE_AUTO) or not doesn't make a difference. The result is both times like on the screenshots earlier. I guess it's because the button is scaling itself to the surrounding hbox container.

Still I think it's important to know. I use almost not stock elements anymore, but I'm sure there are many apps out there which do.
Maybe you'd like to add this information here:
http://wiki.maemo.org/Using_Fremantle_Widgets

And maybe we should continue this discussion some where else as it has not much to do with the topic anymore ;) How about here:
http://talk.maemo.org/showthread.php?t=29500

[kanishou]

I tried it now but it doesn't really make sense.
The thing is, the search text entry field always has the focus. But as soon as a HildonEntry widget has the focus the placeholder text is not shown anymore. So in my case the placeholder text is only shown while panning the list, because this is the only situation that the HildonEntry does not have the focus....

Ah yes, that's not so nice then. But you don't even need the label in the first place, as it should be obvious what it is for based on the context and dialog title. Note that the hildon picker dialog with a text entry doesn't have a label there either.

[kanishou]

That's nice! Thanks :)


I just tested that and in my case calling hildon_gtk_widget_set_theme_size(button, HILDON_SIZE_AUTO) or not doesn't make a difference. The result is both times like on the screenshots earlier. I guess it's because the button is scaling itself to the surrounding hbox container.

Still I think it's important to know. I use almost not stock elements anymore, but I'm sure there are many apps out there which do.
Maybe you'd like to add this information here:
http://wiki.maemo.org/Using_Fremantle_Widgets

And maybe we should continue this discussion some where else as it has not much to do with the topic anymore ;) How about here:
http://talk.maemo.org/showthread.php?t=29500

You have to set it to HILDON_SIZE_FINGER_HEIGHT. HILDON_SIZE_AUTO is what it does by default. :) The point is that the theme engine can choose graphics that are not meant to be scalable in height and thus can look better. It will also ensure consistent sizing of the widgets.

I will have a look at the links you mentioned, thanks.

[conny]

I will have a look at the links you mentioned, thanks.

I would be great if you could add a small section about buttons and the different sizes here: http://wiki.maemo.org/Using_Fremantle_Widgets