Re: Meego vs Android apps (C or Java?)
 

Well, QML is very, very much more powerful than this. In fact, you CAN create games using QML and C++, and I'm not only talking about 2D games (http://quitcoding.com/?page=work#5inarow), but also 3D ones (http://labs.qt.nokia.com/2010/08/10/qml3d-demo/).

Re: Meego vs Android apps (C or Java?)
 

I have one small point to add. Isn't Symbian written in C++? I don't see any recompiling done there. The same app will run fine on an N95 and on a N85. The same app will also run fine on an N8 and C6. So why should an application, just because it is written in C need recompiling?

If the vendors stick to the same architecture and Meego is programmed to cater for these differences, I don't see why it can't succeed. If Meego gets seperated in x86 and ARM..there's the big problem then...

Besides even if apps have to BE recompiled, it might prove a good idea in a developer's point of view. It will seriously hinder piracy for one thing. In Android, there are torrents with 3000 pirated apps and games. These will work on every Android phone there is. If they needed to be recompiled, they could only work on one phone only.

In a user's point of view it would prove useful to have an app for a certain phone only. What if a phone comes out with some type of Kinect for example? Would a developer bother developing the app to use it if all other phones don't have it? But having an app specifically for that phone would prove useful.

These are all what ifs after all. There's absolutely no reason why being written in C should require any recompiling. The OS should handle everything from scaling of different resolutions to the way different architecture might handle it. I don't see any games on a PC having to be recompiled to run on a Pentium 4 or a Core I7. Or having to recompiled to run on a different resolution. It is ridiculous to suggest this should be done on mobile platforms. The OS should handle these things. The OS should be slightly modified for different platforms, but that's it. It would still be more efficient than a VM environment.

Symbian does this well. Meego should too. (I used the word should..).

Re: Meego vs Android apps (C or Java?)
 

Those are not different architechtures: they all sport ARM processors. Thus there is no recompilation needed. It would be different between Atom-based MeeGo device and an ARM-based one: there you'd need recompilation. I don't think that will be a large issue though as most portable devices where MeeGo is aimed for are ARM and will continue to be ARM.

And the OP was incorrect: native Qt apps are C++, not C.

Incorrect. Look above answer.

Re: Meego vs Android apps (C or Java?)
 

I think this is all wrong.... Nokia and Intel would not spend time, effort and resources to make an operating system that is "App-centric" but requires the developers to tweak all their apps for each device.

What is taking a long time is to make this a platform perfect from the get-go (unlike WP7 which was rushed before Android dominance became too difficult to penetrate).

Nokia and Intel are trying to make a developer kit on Qt ... that once you create an App using those libraries, it will be supported on ALL Meego devices regardless of processor diversity (ARM) or even architecture (x86 Atom). And this makes sense, nothing else does.

And if that is not the case (ie all apps need tweaks for different devices or architecture) then Meego will fail badly, along with Nokia (and at best they will be in the niche like Palm).

Re: Meego vs Android apps (C or Java?)
 

No. I' just saying tha apps written for Android 2.2 will work for all phones out there tha use Android 2.2 and most probably in most future androids (unless of course it requires specific hardware like a magnetometer).

I'talking about the application packages. Not the OS.

And python is not considered VM-base like Java. It is conasidered to be interpreted and it doesn't need recompilation, even if it uses a VM internally.

As for QML, it is not adopted yet so until I see something big written in it I prefer not to consider it.

Re: Meego vs Android apps (C or Java?)
 

Try considering the example I mentioned elsewere: MeeGo becomes an Atom-based success and HTC introduces an ARM based device. How will OVI work in that case? Will there be any application available for the HTC phone at the begginning?

For ovi to support multiple platforms:

1. The vendors must provide multiple binaries, which is only possible for phones that are already released, or
2. It must become a repository where the developers will upload source code (practically impossible for non-opensource apps).

The more I think of it, the more I believe that it will alienate other phone vendors...

But part of the original question still stands: Did Nokia and Intel consider this?

Re: Meego vs Android apps (C or Java?)
 

Qt simply doesn't work like that, it is not a VM-language nor interpreted one. A Qt app compiled for ARM will not work on x86 (Atom et al) and vice versa, it needs to be re-compiled.

Re: Meego vs Android apps (C or Java?)
 

That would mean there will be at least two developer kits. One for ARM-based and one for x86-based. And if that's the case, MeeGo will be fragmented upon birth.

I'm having a real hard time believing Nokia and Intel went to all this trouble for that. (I mean if that's the case then Nokia didn't really benefit by teaming up with Intel - contrary to what they said).

I don't know, something smells fishy.

Re: Meego vs Android apps (C or Java?)
 

A few thoughts for you.

No, it's C++.

Correct.

It isn't an obstacle at all.
In Qt Creator I can compile my app for the desktop and also ARM, all with a push of a button. AFAIK MeeGo's OBS (build system similar to Maemo's Autobuilder) also compiles for both ARM and x86 automatically.

Re: Meego vs Android apps (C or Java?)
 

No, you don't understand. I don't know if you have any programming experience or not, but anyways, the same libraries, kits, source-code and all can be used, you just re-compile the app. No need to modify anything or create two sets of source-code or anything like that. It simply means that you can't just copy the same binary file from ARM device to Atom or vice versa.

I don't see why you think there would be the need for several entire development kits, it simply doesn't work like that.