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).