Re: Portrait mode use cases
 

I haven't had time to read this entire thread, but autorotation of the entire UI is a must for me. I champion one handed usage, and with a touchscreen, it is mandatory to have it.

Has anyone looked at Android and how it handles autorotation of the freely placed widgets on its desktops?

I think going forward, since the widgets are freely set, they should have separate placements for landscape and portrait modes, and when rotating, the widgets should animate and move to their new locations with each rotation.

Another is to keep them still and only rotate the content within the widget box, which is a bad idea in my opinion. Keeping the widgets' orientation static as the screen rotates may not suit the content within.

Re: Portrait mode use cases
 

Elimoon8 has already proposed an idea for Widgets. It is very interesting and quite easy to make.

Re: Portrait mode use cases
 

I have a question:

When a software goes to vertical mode, is this his window that rotates 90deg and resized or is it the X Window server?

If it's X Windows, it's no need to rotate 90deg widgets: simply reverse their coordinated X and Y.

And during the first rotation, after placing a Widget, Maemo can correct automatically coordinated of the Widget if it exceeds the screen.

After, be it Maemo which corrects any single the position of the Widget, or be the user moves it, Maemo remembers hes position in horizontal mode and vertical mode.
Thus, the widgets will have different positions for the vertical mode and horizontal mode. Like the very good idea of Elimoon8.

Re: Portrait mode use cases
 

Look what I found (credit to Marcelo Eduardo off course)

http://www.flickr.com/photos/handful...n/photostream/

Re: Portrait mode use cases
 

That's not the only noise in the market. Slashgear makes specific mention that one-handed tweeting on-the-go isn't realistic with the unit in their review:

http://www.slashgear.com/nokia-n900-...video-0455122/


}:^|~

Re: Portrait mode use cases
 

I should add, it's not negative, but it is being noticed.

}:^!~

Re: Portrait mode use cases
 

The thing doing the rendering does this. Nowadays its all GL, so I think Clutter handles this. So the software would check if X > Y or not and tell Clutter to draw horizontally or certically.

PS: MPX and XI2 is only recently being included in X.Org.

Re: Portrait mode use cases
 

I want to create concepts for the n900 desktop rotation. I *may* not have time to do it myself, but I'm sure if the following things were available, *someone* with moderate image editing skills could do it.

Things needed:
- Actual pictures of all 4 desktops from a user. The messier, the better (it'll help to figure out how the rotation will actually work). Remember to blur out anything you don't want us to see.
- A picture of one of those "dialog boxes" that popup near the bottom of the screen (one of those that you can dismiss by just touching outside the information/confirmation box.
- An idea of the actual font used in the n900 system "dialog boxes." This could help make the concept pictures more realistic.

Re: Portrait mode use cases
 

I agree... I hope there will be any day in the future a portrait version at least of the messaging (sms) and browser section...

Re: Portrait mode use cases
 

I've red most of the thread and I didn't understand, does it support portrait mode "the first screen after unlocking? Do I need to slide my thumb over a line or just flick the side button. For example, I'm holding it in portrait mode with one hand and what..... always when I unlock it somehow, the calling pad activates...?? I hope I am stupid..... :confused:

Re: Portrait mode use cases
 

Check out this crazy gimmicky video of Sony Experia x2's way of handling multi-oriented home screen:

http://www.engadgetmobile.com/2009/0...irst-hands-on/

Re: Portrait mode use cases
 

Lol... WinMo 6.5

***

The problem as I understand it isn't so much the home screen, or multiple desktops, or even the dang dashboard by themselves... The problem is consistency among all applications while managing multiple tasks.

I am pro'ly wrong (as that is about to be pointed out :) ) but as I also understand it, this shortcoming may only be with fremantle at this point and will be supported in future releases of Maemo by Nokia.

Is this about right?

Re: Portrait mode use cases
 

I slightly agree. Maemo5 has things I like, but giving up one handed operation will be hard for me. I used to do all of my writing while walking my dog, a 78 lb. pit bull. I doubt I can do that with Maemo and a QWERTY pad. I think T9 support via an onscreen or even better a real keypad would be great. That along with no portrait support for the entire UI are my biggest complaints for the otherwise great device.

Re: Portrait mode use cases
 

jimizzle, I initially clicked Thanks on your post, until I saw you posted the same thing in three threads! Please just post once.

Re: Portrait mode use cases
 

This may be a little bit off topic, but I am going to share you a secret (that can be found from the source code also).

The size and the shape of Mauku Widget is based on the widget's background image. The image is normally loaded from the file /usr/shareimages/mauku-widget-background.png. However, if there exists an image in /home/user/.mauku-widget/background.png that is used instead.

So, if you want to change the shape or the look of your Mauku Widget, just put an image into user's home directory before launching the widget. Portrait mode supported... ;)

Re: Portrait mode use cases
 

I hardly believe I read through this whole thread now... I never even opened it before, because its title almost seemed like an insult: "Portrait mode use cases" - What??? Being a mobile phone is a portrait mode use case. So what else do you want? Why make it sound like landscape only is the reasonable thing to do and users would have to come up with excuses for portrait?

From what I read now, things look much brighter:

My interpretation now is that Nokia is aware of this being a problem and they are in no way happy with landscape only. - It's just that they didn't manage to make full, system-wide portrait mode happen in this release. Accepted.

I also get the impression that this, along with other issues on the phone-side, is the reason for what some of us called Nokia "downplaying" the N900.

I have to admit that during the last few days, whenever I used my S60 phone, I checked if what I did with the phone would be possible with an N900. Very often, unfortunately, the answer was no. A lot of this has to do with one-thumb-usage.

My 2 cents about a portrait mode keyboard:

I'd rather have it numerical/T9-like than mini-QWERTY. The main reason why I'd want to type in portrait mode at all instead of using the slide out keyboard is that I use only one thumb while I walk. It's much easier to hit the right key on a numeric/T9-keyboard than on a small, iPhone-like QWERTY.

Also, everything that has to do with launching and switching applications should be available from portrait mode, given that in all the one-thumb use cases, I'll start from portrait. (If you could do with landscape and 2 hands to launch an application, you could as well continue using it in landscape...)

Looking forward to step 7 of 9 ...

Re: Portrait mode use cases
 

I most like the simple idea of having a *different* desktop entirely for portrait use. This was mentioned by a previous post.

The 'portrait' desktop would have a different customization of widgets, and a different background. Best of all, the widgets would be apps best suited for one-handed use as selected by the user for on-the-go scenarios (eg, large clock on top, message feed in the middle, mp3 player on bottom in portrait vs. RSS feed, photos of mate in landscape, etc).

{:^)~

Re: Portrait mode use cases
 

Application in portrait mode :

http://www.youtube.com/watch?v=VNOHIO8SmI0

Re: Portrait mode use cases
 

im no expert, but i can tell this video is important :D

Re: Portrait mode use cases
 

Looks like "Nokia 2.0".

Re: Portrait mode use cases
 

cool 2 new vids:
http://www.youtube.com/watch?v=zBKSBAaJpc8
http://www.youtube.com/watch?v=R6OnWuZ9mYs

the 1st being more important... he clearly says...that it's not that it couldn't be done (portrait), nor that they wouldn't do it...it's just they thought the features would be better to use on landscape...and if enough people want for eg. the browser in portrait, it could be done...

so, we might get what we want in firmware updates :D

Re: Portrait mode use cases
 

so... the first video show that we can use the picture gallery in portrait mode right?

Re: Portrait mode use cases
 

Oops :) Houston we have been uncovered :) Yes, but the video is really about: The EXACTLY same code running on Maemo and Symbian :)

*ps it's Not nokia 2.0. It's a QT experiment to really try to prove (no IFDEFS) that you can indeed have the same same code on 2 platforms. So in the end.. doesn't matter if it's Maemo or Symbian :) good for developers!


:)

Re: Portrait mode use cases
 

What does 'exact same code running on maemo and symbian' means?
Simply that it doesn't need manual porting work during the build phase, or that they're somehow binary compatible (like OSX with dual intel+ppc binary bundles)??

Re: Portrait mode use cases
 

For a portrait text input method, could the dialer keypad not be modified to allow for alpha-numeric text entry ala your bog standard mobile phone? That seems to be the main requirement here.

Re: Portrait mode use cases
 

So no manual intervention (or if def to allow platform specific stuff to be loaded) when compiling.

After that, we will have PySide (QT bindings) working, then we will have exactly the same "binary" running in both platforms.

:)

Re: Portrait mode use cases
 

They could be using that web framework they were going on about some time back.

In a speculative case, the container for running the javascript/html/whatever could be some natively compiled qt client with an exposed API to system resources (files/sound/accelerometer/etc). If you mirror the client on many machines (regardless of the OS), then the same javascript code will run -- exactly how web browsers work today. The benefit is run-anywhere, easy to develop and test code. The cost is app performance (you won't likely see an PSX emu developed this way).

This is WILD speculation (none of it is real information), but it's a reasonable solution with some very large benefits.

}:^/~

Re: Portrait mode use cases
 

Yes this was wild speculation :)

We are not using any web based stuff. But you pointed out exactly the point : If we go Javascript, python or any other dynamic language you pay the price for performance.

That's why the code is PURE QT, and thus runs on the N97, and the N900 without any modification to the source and no ifdefs.

It would be too simple to use JS on top of QTwebkit :)

The demo is to demonstrate that Nokia is getting there :) real cross platform development :)

BR

Marcelo

Re: Portrait mode use cases
 

This must be what Eldar found exciting and what he hinted to be announced at the event on the 2nd\3rd Sept. Why didn't Nokia simplify the message of 'cross platform apps\developments' that could really rock the news?

I'm not talking about making baseless hype, but a little factual excitement can't be that bad.

Re: Portrait mode use cases
 

This is very interesting indeed. Is there a wine type layer in between on at least one of the platforms? What is the Symbian executable file format like? Is it somehow compatible with elf (assuming maemo apps are compiled to ELF)?

I'm very curious about this (links would be lovely). From what I understand, unless the apps are being compiled to processor-and-os-independant byte-code (which should be entirely possible), this is a hack at best. If for example the processing architecture changes with natively compiled apps, then you'll have to emulate to run apps which can bear a heavy processing/development cost. I think this is why Google went with java as the platform for android apps (uh, I think). Perhaps there's something I'm missing?

\:^!~

Re: Portrait mode use cases
 

I think you are reading too much into the "exact same code" thing. They mean the exact same source code, not binary executable. Each platform needs an architecture-specific compilation done to get an executable. But in this case, it is just that...a straight compile with no modifications necessary in the source code to accomodate the different platforms. The QT SDK takes care of the underlying details.

In this way, it's similar, yet different from Java. Java bills itself as "write once, run anywhere" when it is more aptly labeled "COMPILE once, run anywhere" due to the production of platform independent bytecode and the presence of platform-specific virtual machines on each target. QT, on the other hand, is more strictly "write once, run anywhere" since you write the code once, but then you compile it for your targets.

Re: Portrait mode use cases
 

That's not completely true. If they have the same CPU family (meaning same instruction set architecture/binary-image), and the same executable file format (ELF, DWARF, etc.), then mostly what you really need from there is compatible library layers. That is, as long as no one is doing things like system() calls (ie. stick to QT calls, and things in the libraries you've provided for compatibility, and you're ok).

This has been done, in the past, to get things like BSD based OSes to run Linux and Solaris binaries. All it takes is: same CPU, support for the executable file format, and a set of compatible libraries. And, really, that's what WINE attempts to do (it's not an emulator, it's cross platform library linking, for the MOST part). WINE just doesn't have a full set of libraries and library definitions from which to build up that environment.

Symbian and Maemo don't have that limitation -- each team can easily talk to the other. And the QT team is in that same community. I'm willing to bet that they have more than enough opportunity to develop a full scope of library definitions for providing a complete common executable environment that can run 1 exact binary image on two OSes.

My main question would be: is it

• a Symbian library set (would run on any OMAP+ELF?+Symbian+QT system),
• a Linux library set (would run on any OMAP+ELF?+Linux+QT system),
• a Maemo library set (like the last one, but requires some Maemo specifics),
• pure QT libraries (no Symbian nor Linux/Maemo calls allowed, but would then run on any OMAP+ELF?+QT system), or
• a completely different executable environment (that wouldn't run on a straight Symbian+QT environment, nor a straight Linux/Maemo+QT environment, it would require OMAP+ELF?+QT+this-extra-library)

Re: Portrait mode use cases
 

I guess I should have been more specific in my use of the term "platform". In my world, "platform" necessarily implies hardware architecture unless otherwise specified (with the term "environment" referring the the OS/toolset unless otherwise specified). In the case of existing symbian devices (such as the E71) and the N900 (the comparison for which the demonstration was made), these cases would be different platforms even if they were both running the same OS or not, and thus would need a re-compile in order to fully take advantage to the respective cpu instruction sets (is there a performance-hindered, but compatibility-maximized least common denominator for the ARM series like there is in the intel world by compiling to "target=386"?). That was the point I was trying to make in reference to Cap'nCorrupt's questions/musings regarding an emulation layer to make the applications work cross-platform: They will either work because they can run natively (ie identical binary) due to the same platform or compiled to some least-common-denominator platform, or they will need to be recompiled. There is no vm/bytecode equivalent in the QT world as there is in Java, nor is QT a "just-in-time" language like python...and there's no emulation layer that's acting as glue to create the cross-platform capability. QT is basically a macro-ing engine for C++ if you want to get down to brass tacks...with the SDK handling all the "IFDEF" stuff for you behind the scenes. All the other usual restrictions regaring re-compilation remain the same as they would for a C++ application.

Re: Portrait mode use cases
 

You'd have to stick to a lowest common denominator (which can be really low, depending on how old Symbian/ARM sets do you want to support) and at that point it's not that attractive anymore (as you loose all the fancy extensions which actually constitute a large part of the improvements).

Re: Portrait mode use cases
 

Right. For the devices given, we're talking about ARMv6 (N97 and E71) vs ARMv7 (N900) instruction sets, right? Hopefully the set of common instructions/features between ARMv6 and ARMv7 isn't too restrictive.

Same with the Symbian in use -- I'd bet it's rather recent. And, while I've never done low level Symbian coding (nor high level, for that matter), it's my understanding that it does a good job of abstracting away specific hardware (peripherals and peripheral configurations, and such), just like *nix platforms tend to do. So, a difference in peripheral modules probably wouldn't keep you from running the same application.

Re: Portrait mode use cases
 

Well, kind of. The problem is that ARM is not as incremental as x86 is (in order to provide minimum silicon that can do the job), so in each generation you have several processors with different feature sets, with a basic common functionality. Even if you restrict yourself to ARMv6 in general, you have to drop VFP, Thumb2 and whatnot as not all ARMv6-es have them (not to mention you're compiling for the wrong pipeline and cache sizes). The point is that on mobile devices overhead directly translates to lower battery life, so, unlike x86, you really want the best optimized code in there for that particular unit.

Re: Portrait mode use cases
 

Haha.. I love this community!

In this day and age, I think that bytecode is the way to go. I feel there's a good performance to portability tradeoff.

Considering a long-term play, android, for example has the advantage of quickly being able to jump to many devices with without sacrificing the app library. Not so for apps that require a re-compile, even if it is simple recompile. For each additional piece of hardware, a new compile must be done for each app in the library. Of course, you can always distribute source, but this has it's own set of consequences.

I think an app layer like QT is good for portability but it is old-school-chic. In the age of bytecode interpreters, and more-than-before cpu options, it makes sense to distribute in a write-once/compile-once, run-anywhere manner.

Oh yeah, and portrait orientation rules!

}:^)~

Re: Portrait mode use cases
 

It depends on how performance intensive the app is.

The good news for byte code is: it's portable to every platform that has the interpreter. And as time moves forward, and CPU's upgrade, it not only retains that application ecosystem, it gets faster at running those apps.

The bad news is: native will always do better. Handheld games that really push the envelope of a given platform will always do better than a bytecode version of the game. You can somewhat mitigate that by doing JIT compiling (or "compile to native at install time"), but not everything with JIT, or bytecode-to-native, does as well as something written to native APIs.

I don't think either strategy will eliminate the other. The best would be a platform that gives developers the ability to pick between bytecode apps, native apps, and hybrid apps. (Android, as far as I recall, only gives you "bytecode" and "hybrid" options, where hybrid means "mostly bytecode, but with some API's to call out optimized native code for some parts of the app)

In that regard, I think Maemo is much better positioned than iPhone-OS-X or Android. The possibility to get a JVM on it is there. The possibility to get Dalvik on it is here (and I wish someone would do both of those). And you've definitely got the ability to do fully native code. I don't see Dalvik for iPhone coming out, nor full JVM for Android (nor a fully native environment for Android) coming out.

Re: Portrait mode use cases
 

Do you realize post #225 was the last on-topic in this thread?

The discussion about Qt portability is *very* interesting but don't expect anybody finding it under a thread about portrait mode in Maemo 5.

Can you please continue in a new thread? And can admin please move all these posts there? Thank you!

Re: Portrait mode use cases
 

Yeah, not to go back on topic or anything...

Anyway, I know this has been said ad nauseum, but just want to remark that I, too, consider a near-universal portrait mode a must. Android -- even from the outset -- did that rather well. But it lacked a text entry mode for portrait, which was really irritating. Sure you could turn it and flip out the keyboard and use two hands -- no doubt about it, that's really easy to do. But It's also pretty easy to reach into your bag and get out your laptop -- but for all of us here, the convenience (and inconveniences) of an N8x0 are worth not having to do that. Especially for a device intended to reach a broader audience -- people who aren't willing to inconvenience themselves for the benefit of their devices -- that's an unacceptable limitation.

At least the iPhone only allows landscape where it has a landscape keyboard. It never fools you by allowing landscape and then not having a way to enter text. I think if the N900 does this, it will be a big mistake. I suppose, then, from the outside, until there's an OSK, only applications that will seldom or never take text input should be portrait enabled, like the media player, phone dialer, etc. And, frankly, that's a shame.

$800+ US ought to buy a whole lot of convenience for the user (especially since nowadays many other higher end smartphones can be readily acquired, albeit not necessarily new, but sans contract obligations for $500 or substantially less).