Hei Zerojay :

I understand what you've saying.. but I didn't forget my post from the past :
1) Canola stays simple.

Why ? Because the version that will be launched is exactly the SAME as the old one, improved :
Music. Video. Photos. Shared (UPNP) and Media
the only difference is to workaround a major problem...(upnp servers) we separated it in it's own menu.

Carman, webkit etc, are just "experiments". Why? Because for selected people (interested) in use Canola in their car, Carman makes sense. Instead of installing 2 applications, go to the website and install a simple plugin (but canola remains basic)

Webkit? We don't care about browsers.. we just want to be able to draw on the screen the PODCAST description, or even another kind of html rich text, that is a standard today. Unfortunately the only way to render html text / info is to have a runtime. We are just playing around with the one that eats less memory, because the use is pretty simple.

So please =) there is no play random things, everything has a reason when we are showing experiments... the real thing is only the basic media player, evolved to fit the request of the users.

"album art", "podcast download", "picture thumbnails", "better scanning", "less cpu usage", "less memory usage", "no web configuration" etc.

So the vision stays quite clear :

To be a simple, finger driven environment to consume multimedia and internet content on the nokia tablets.

*if it's in the car? =)

**Forgot one thing: that HUGE amount of balls you can see in the second video are actually duplicated just to make sure the menu is correct, is not meant to be a menu like that. but if we end up with only 10 features or so, we can throw away the sub menu and be even simpler =)

*** I think Patricia ( who designed the icons) would be quite happy because a lot of icons would just die hehhee

Is there even an outside chance the new Canola will run on the 770?

According to Marcelo they have a version running very well on the 770.

Well, to be REALLY honest, we did almost all the development not testing on the nokia 770. We thought "Dude this is so cpu intensive, it's never going to run on the 770" but we did test it and it was really nice. But we didn't do a full test (doing right now) to see if everything goes really really nicely as in the n800. But It does run there and with less tearing =) so it looks sometimes even better than in the other devices.

My concerns are with the picture application ( lot's of reading / displaying images) and scaling them sometimes can make the 770 sweat a little bit more, so for example multi tasking can suffer.

There's one REAL problem though: the screen sensitivity is quite low when compared to the newer devices, so it can be quite hard to use with the fingers : / But I think pressing a little bit harder can help.

Let's see how it goes on that, but we would be really happy to fully support (at least the HE edition)

BR

Thanks for the fast reply Handful and for the ray of hope too. I'll keep my fingers crossed - and maybe start saving for an N800! It was the picture viewer I was most looking forward to

Ok, thanks for the followup to zerojay's post marcelo. Makes sense to me now, at least.

I'm looking forward to this. Especially the image viewing aspect.

Newbie questions:
Did you use scaled down images in the demo?
And does it generate a thumbnails database?
Or work on the fly based on the files present in a certain folder?

By any rate, a big two thumbs up for all the great work

Actually what this seems to mean is that the new Canola is an alternative framework and runtime environment for Maemo apps. When the plugin architecture and the widget set have matured there will be a new option for Python developers on the tablet.

Today we have :

1) use pyGame and do pretty much everything yourself UI-wise,

2) use Glade to describe the UI and PyGtk, the Hildonized API and widget set, for a traditional windowed look.

Tomorrow there will be :

3) write a Canola plugin. This means using the Enlightenment Foundation Libraries tools :

- describe the UI in Edje syntax (or some design tool that exports it), probably using some high-level Canola widgets,
- code the behaviour using the Python bindings to ecore/evas created by the Canola team.

The 1-to-3 numbering also reflects these orders :

- from platform-agnostic to platform-specific (Any/Hildon/Canola)

- from slow and memory-hungry to fast and lean. If you've tried the two demos available in maemo.org/extras (especially the iPhone-like soft keyboard), you'll know what I mean.

So Canola may end up being used to host apps that have nothing to do with multimedia (like Carman), just like Nokia used Mozilla and XUL to build the recently released IT Video Converter, which has nothing to do with Web browsing... could be fun :-)

this looks amazing

Fpp:

The possibility(*) is just that. because in the end what we saw was: People wanted a lot of features and fixes, and we needed a way to develop the neat UI's as fast as possible. Pygame / sdl are som simple that it wasn't enough to what we needed. So what was the goal :

Create a infrastructure that makes pretty easy to do crazy stuff on top. This crazy stuff today is our media application.

EFL is just great. We got pretty close to Rasterman since bossa and that was crucial to define that EVAS was really what we need. For those who don't know edje is incredible flexible, fast and easy to build rich uis (of course can evolve a lot) and evas is fast. So put this 2 guys together with a lot of optimization work (Opensource) to convert it's software rendering to 16 bits and all the python binds to fit your needs what you get is a REALLY nice tool to work with. The best part : whole thing has 600k memory footprint (approximately) and yes, FPP is right we are consuming a lot LESS memory than the old canola, and a lot less memory than any other pygame-sdl based application.

I'm really thrilled to see this "speed up" in development in practice in the last 5 weeks, and more excited to think that people will now be able to use the whole thing in their own plugins.

But the simple thing remains from now : From us, canola still a media thing =) if you want to make it more, it's up to your, but the real end user gets the simple part of it, that we will make sure it runs nicely, smoothly and most important : this time we will not be quiet, Canola will have a very fast and responsive dev team, with new features, bug fixes being deployed in scheduled dates in small time frames.

As we think that people can use some of the same tools: we already released the plugin we use to export psd layers to edje_editor (so developers don't need to go there positioning and write edje verbose code and worry about pixel position) we just finished the version of the plugin for photoshop (great work by miguel btw) and this will also be open to those who wants to experiment. Along with that we also giving away some real nice icon templates, theme guidelines, and tutorials on how to compile it.

There's more on canola than you have seen on the video, and it's only possible because we realized that although SDL / pygame is quite nice, it's just not flexible enough to the thing that is really important in great UI design / development : late change.


That made, (took a lot of time) now we are just "putting pieces" together, and to be able to do a smart work we are doing everything the way that we think is pretty organized and has a great re-use potential.

What we have learned: Rich ui demands a complete different thought UI toolkit, and we didn't want to revolt against anything or fight to change something that has other goals ( GTK ) so we looked for something that was created with rich ui in mind.

We will have those who want to play with canola plugins, and for sure see what can be made, but like you said Fpp : it's quite easy to do crazy stuff with EDJE + Evas and python. Now it will be time to have those applications for 2 purposes :

1) to supply the author's needs for something (or his friend.. or of a group)
2) to put out framework to test and to identify future needs.

We are so simple that we cannot predict what users will need, but with plugins coming out we will be able to at least to take a glance on what's really hot for the future!

*update: I forget to wrote the * : I wanted to point out that because we needed a nice framework to work on (with) python it was a happy consequence to have the same thing available for developers.