You have to click on the app in app manager and look at the installed size; the "size" that it shows on the listing page is just for the specific package, not its dependencies. Of course, you can always just look at the dependency list at that point, too.

On an unrelated note, an N900 user walks into a bar...

You are wrong. The size in the list is the download size. If you didn't install the dependencies before, they will add up.

Anyway, the point was different. What I originally meant was that if you don't have Python installed, the apps that require it are easily spottable.

Now back to the topic. I think the most interesting question is which engine the WRT will use - gecko or webkit?

Doesn't post #1 in this thread by qgil strongly imply webkit, at least for maemo 6?

It will be based on webkit.

A couple of weeks back I was fortunate enough to meet Rajesh (the guy who made many of these slides) and asked if the move to Qt in Maemo6 would affect their choice of gecko as the microB browser engine.

I was told that they would continue using Firefox as the main browser, and Webkit would be the preferred rendering engine for web apps.

Makes a lot of sense to, gecko is generally better from a compatibility perspective, and webkit is much lighter. Not to mention webkit 'comes for free' with qt 4.4+ already.

Of course that will mean two browser engines in memory, so they better be prepared...

It just gets worse. :/


Hmm that's actually true. I remember being curious about this a while back when deciding how to do a package and had come to the wrong conclusion. I'm glad HAM is doing it closer to the "right" way.

Am I the only one finding your comments in this thread hilariously ironic considering your signature?

I can see that some might see it that way, but it's not really the case. Adding a mandatory javascript app layer to an OS doesn't add functionality, it takes it away (less battery life/performance). You can't do anything new with it that can't be done better without it. I.e. not really a feature...

It's rather like Apple calling the no user multitasking a feature, or the nonremovable battery. Both are "features" that restrict user options.

Edit, rather than continue posting off topic: i can see the point that it is a feature to developers in your reply, but would argue that in this case that does not imply a user feature, and here's why.

First, battery capacity is the one mobile device hardware component that is essentially stagnant. The only way we get better battery life is by using a bigger battery or making the software or hardware more efficient. Moore's "law" has made a pocket computer phone a possibility in the N900, but we already know the M6 device is going to be using the same SOC--in fact, it's almost going to be the same as the N900 in hardware--so we're really not getting a significant bump in efficiency from the hardware. At the same time, we'll probably see more RAM and hopefully a magnetometer and bigger screen. It seems to me that the N900 has sufficient battery life, but only just.

Now, given that, what would your strategy be to evolve N900/Fremantle into a killer device that is going to rule the high-end mobile device world, one that will be light enough to get greater market penetration and have battery life to break into the much larger market of people not specifically looking for a computer?

Well, i'd use step 4 to hone and refine the software and drivers so that step 5 can slim down and last longer. So that it actually represents the lean, mean product of 5 steps of evolution, rather than the fifth step in a tech demo random walk.

Let's see Nokia's plan: hey, let's throw in an extra layer of cruft that takes up a large chunk of RAM and more cycles. Maybe we can draw developers from Palm, Android, and iPhone so that we can pad out our repo with lots of shiny apps and won't have to use these old boring compiled ones our community has been polishing and refining for a few iterations. By conforming to the rest of the mobile device world, we can really make our product stand out. After all, we have universal name recognition as a provider of great apps, ergonomics, PDAs, and polish. Why would anyone in their right mind not flock to our banner then?

Hmmm. My second point was going to be that reducing the barrier to developer entry to that degree doesn't promote useful development or apps, but i don't really think a second point is even necessary. This has all the earmarks of a pointy-haired manager at the wheel, so i guess we can just hold on to our owls and hope for the best.

I tend to look at it in the light that User Freedom is (in most cases) directly proportional to Developer Freedom.

It's true that 2 different browser engines are going to use more resident memory, and CPU cycles if both are in active use simultaneously. The same is true of including both GTK+ and QT4 widget libraries.

I really only think we will see a significant battery hit if developers misuse the feature, and ignore these relevant concerns, the same problems we already see with native widgets and apps.

It fits with nokia's stated vision of Maemo, the desktop experience on a mobile. How many rendering engines do you have installed on your desktop?

We're still on the cusp of such an experience being at all feasible on devices of this size. But the amount of memory nokia will be able to cram into these is only going to get bigger.

Its not really the same. Javascript is both slow and hits directly the processor (for a longer time than native) even if lazy loading is used (if evaluation is postponed, it will hit the CPU eventually with the exact same results) and regardless if it is misused or not (you will probably have access to underlying libs to speed up some calculations, but for GUI you're alone with HTML and JS in your hands).