View Full Version : Quim keynote on Maemo's switch to Qt as the main toolkit
From Vincent Untz's blog entry:
Quim just gave his keynote, announcing that maemo will switch to Qt as the main toolkit in the future (http://www.vuntz.net/journal/post/2009/07/04/Nokia-GNOME-Mobile), with GTK+ being a part of the maemo platform that will become supported by the community.
The included slide details the GNOME/Hildon/GTK+ technologies still being used or considered for Nokia's Maemo platform.
That's a huge leap from "Qt support (http://wiki.maemo.org/Task:Maemo_roadmap/Harmattan)" and more than a little brave since Qt won't even be officially supported in Fremantle.
Is not != won't be . There is Qt commynity port lead by Forum Nokia and that is not at the moment part of the official Fremantle release. It don't mea that you don't have full Qt for Fremantle.
Everyone that like to develop Qt applications for Fremantle can use the Qt our Qt port.
allnameswereout
07-04-2009, 05:41 PM
That's a huge leap from "Qt support (http://wiki.maemo.org/Task:Maemo_roadmap/Harmattan)" and more than a little brave since Qt won't even be officially supported in Fremantle.I thought it was pretty clear Qt would be supported on Fremantle, and default on Harmattan...?
javispedro
07-04-2009, 08:04 PM
Oh well. Time to remember how to write .pro files again.
The only problem I see with this is the two API breaks (5 & 6.0).
And I hope the resulting platform is a not a mess with any sane application needing to link with both gtk and qt.
GeneralAntilles
07-04-2009, 08:16 PM
I thought it was pretty clear Qt would be supported on Fremantle, and default on Harmattan...?
The statement made at the Summit last year was that Qt would be community-supported in Fremantle and officially supported in Harmattan.
There's no turning back now...
Slashdot is covering Nokia's Maemo Switching To Qt (http://tech.slashdot.org/article.pl?sid=09/07/04/2155209).
There is Qt commynity port lead by Forum Nokia and that is not at the moment part of the official Fremantle release.
I must admit I'm a bit confused on the meaning of "support" / "community support" here. I find it hard to believe that Harmattan firmware will ship without GTK+ & Hildon. For one thing that would mean Nokia would have to rewrite every GUI app/component from scratch, including some decidedly non-trivial ones like modest and microb. For another, installation of practically any pre-existing third-party app would pull in the GTK+ stack as dependencies, so it might as well be preinstalled.
On the other hand, if GTK+/Hildon are part of the official firmware how would the community be able to support (publish updates and so on) them?
Some clarification would be very welcome please.
Everyone that like to develop Qt applications for Fremantle can use the Qt our Qt port.
Sure, Qt is even available for Diablo. That's fine (although having two large-ish GUI runtimes in RAM seems wasteful), it's the dropping of GTK+/Hildon support part that's surprising.
With gtk they made the mistake of requiring hildonization instead of transparently make gtk applications to work.
From what I read about the community supported qt that is not strictly necessary with it (unless they "fix" it in harmattan).
ragnar
07-05-2009, 07:29 AM
With gtk they made the mistake of requiring hildonization instead of transparently make gtk applications to work.
From what I read about the community supported qt that is not strictly necessary with it (unless they "fix" it in harmattan).
Well, just "making them work", technically, wouldn't mean that their UI's would be usable on the tablet screens.
Hi, this topic started in another thread but I guess you want to discuss more here.
About the switch GTK+/Qt in Fremantle/Harmattan, providing commercial support on both frameworks for both releases implies an amount of work that we simply can't nor want to commit. Qt in Fremantle is in pretty decent shape now and we expect to fine tune it more to make it a realistic option for developers in Fremantle. GTK+/Hildon support in Harmattan depends nowadays on the interest to support coming from players other than Maemo Devices (the Maemo community, the GNOME Mobile initiative, else...). Technically it shouldn't be that hard to port the related libraries to Harmattan and allow the current applications to run, even if not fully integrated. We can help, but the initiative needs to come from someone else. The good thing is that there is a whole Fremantle maintenance period to think and discuss this.
The Maemo API in Harmattan will be Qt based and this is all what application developers willing to deal with the native environement will need to care about. But... actually I don't expect the majority of developers willing to deal with native environments by the time Harmattan goes aout, and actually the GTK+/Qt or even C/C++ will sound to far from their interests and concerns.
GTK+/Hildon won't be used by the applications shipped with Harmattan out of the box and therefore won't be pre-installed. When we say that GTk+/Hildon will hopefully be there as community supported we really mean that. If all things go well developers interested in these libraries would find them in Extras, just like they are finding e.g. the Python bindings there now.
You can't really compare the GTK+ in 2005 and Qt now when it comes to mobile UI friendliness. You can't compare either the position of the Nokia developers working on the first Maemo release under the hood that time and the position of the Maemo developers now that the intentions about Qt have been communicated, even before Fremantle is out. For these reasons it is more feasible to say that plain Qt applications should be able to work in Harmattan much better than plain GTK+ applications have been able to run in Maemo until now. But be aware that Maemo will develop a lot more on top of the Qt & Qt Mobility APIs, as explained yesterday in the presentation (I will link to the audio file asap).
Audio (the network is really slow here and I'm not able to test it, let me knoe whether the file works please): http://tinyurl.com/lvugfd
Slides: http://bit.ly/nkGtw
Well, just "making them work", technically, wouldn't mean that their UI's would be usable on the tablet screens.
The ones I tried under mer/lxde would be perfectly usable if an onscreen keyboard automatically popped up in input fields and there was a way to emulate a right click.
Blog post: http://flors.wordpress.com/2009/07/05/maemo-harmattan-keynote-at-gcds/
The ones I tried under mer/lxde would be perfectly usable if an onscreen keyboard automatically popped up in input fields and there was a way to emulate a right click.
Right mouse button is just one issue. There is many other
issues need to be taken under consideration. One big thing is
dialog layouts. If dialog is so large that part of it is outside of screen
it decreases usability of lot.
Even if you can make technically usable it does not mean
that usability is good. For small screen devices application
with good usability should be usable with finger. As example
acrelling from content pane is much more usable than tiny
scrollbars that require usage of stylus.
Maemo Qt port takes care of most of technical issues like
style and input method but it can't fix bad or unsuitablenUI design.
I strongly recommend that everyone that ports application to maemo
pays some amount of attention to usability and is just not
trying to make quick and ugly port.
Audio (the network is really slow here and I'm not able to test it, let me knoe whether the file works please): http://tinyurl.com/lvugfd
It works, but 24' later[1] I'm still confused :-(
I don't have strong feelings about either toolkit, but the switch (as opposed to both being available and equal) doesn't make sense to me. Apparently (11:48 onwards) the main driver for this seems to be cross-platform compatibility in general, and with SymbianOS in particular. That's a bit... naive to say the least. Portability is a lot more than skin deep, and there vast differences between the two OSs in basic things like file and network I/O, process control and signalling etc[2]. Even more significantly, the middle layer (d-bus, bluez, telepathy, gstreamer and so on on the Maemo side) is completely different. I'm sorry, but "recompiling and it more or less works" (17:26) just isn't going to happen for anything more complex than "Hello, world".
On the other hand GTK+ is (http://www.gtk.org/download.html) reasonably cross-platform and there's even a port to Symbian OS underway (http://code.google.com/p/gtk-for-symbian/). Glib has already (http://opensource.nokia.com/projects/openc/) been ported by Nokia too. Dropping GTK+, Hildon, all existing official apps[3] etc for "cross-platform compatibility" sounds like something that could only be imposed on the Maemo team from above by someone who has no real understanding of the technologies and issues involved[4].
Anyway, since it's fait accompli now, one question that becomes particularly important for prospective developers is: will Maemo 5 devices run Harmattan?
[1] Whatever happened to text btw, you'd think news as big as this would rate an announcement on maemo.org at least
[2] P.I.P.S. is incredibly buggy and if anyone considers it for production use they're in for some very interesting times.
[3] I don't envy Andre the reaction to the inevitable "WONTFIX for Harmattan"[5] storm
[4] But it does finally explain the castration of input methods :-(
[5] Not to mention the also inevitable regressions and new bugs introduced by rewriting everything for no good reason.
Right mouse button is just one issue. There is many other
issues need to be taken under consideration. One big thing is
dialog layouts. If dialog is so large that part of it is outside of screen
it decreases usability of lot.
This also happens under desktop linux. A netbook doesn't have much more screen real estate than a tablet and kde4 works pretty well there.
Even if you can make technically usable it does not mean
that usability is good. For small screen devices application
with good usability should be usable with finger. As example
acrelling from content pane is much more usable than tiny
scrollbars that require usage of stylus.
I personally prefer tiny scrollbars than devote scarce screen real estate to improve finger friendliness (see above).
That's my point of view, of course I cannot say it's the right one for everybody, but it is right for me.
Maemo Qt port takes care of most of technical issues like
style and input method but it can't fix bad or unsuitablenUI design.
Again, this is the same for desktop linux.
I strongly recommend that everyone that ports application to maemo
pays some amount of attention to usability and is just not
trying to make quick and ugly port.
While this is true, a working but ugly application is better that one not working at all.
I personally prefer tiny scrollbars than devote scarce screen real estate to improve finger friendliness (see above).
If you allow scrolling by dragging content pane, you don't lose
any of the valuable real estate to scrollbars at all.
VDVsx
07-05-2009, 10:49 AM
Audio (the network is really slow here and I'm not able to test it, let me knoe whether the file works please): http://tinyurl.com/lvugfd
Slides: http://bit.ly/nkGtw
Thanks for the audio Quim !!! (nice music in background ;))
VDVsx
07-05-2009, 10:53 AM
It works, but 24' later[1] I'm still confused :-(
I don't have strong feelings about either toolkit, but the switch (as opposed to both being available and equal) doesn't make sense to me. Apparently (11:48 onwards) the main driver for this seems to be cross-platform compatibility in general, and with SymbianOS in particular. That's a bit... naive to say the least. Portability is a lot more than skin deep, and there vast differences between the two OSs in basic things like file and network I/O, process control and signalling etc[2].
Well, QT handles network, files and I/O, so not a problem here.
If you allow scrolling by dragging content pane, you don't lose
any of the valuable real estate to scrollbars at all.
But it doesn't work very well (at least in the current implementation) when the content has active spots (e.g. hyperlinks) and you accidentally hit one of them.
Besides, you lose visual feedback on where you are on the whole document.
Edit: and if you're browsing a big document you can quickly go anywhere with a scrollbar, not so dragging the content pane (and IMO inertial scrolling makes things even worse).
I don't have strong feelings about either toolkit, but the switch (as opposed to both being available and equal) doesn't make sense to me. Apparently (11:48 onwards) the main driver for this seems to be cross-platform compatibility in general, and with SymbianOS in particular. That's a bit... naive to say the least. Portability is a lot more than skin deep,
Naive? The Qt developers at Nokia probably know well the complexity of this goal. At the end is their code and they have got some experience about cross-platform development over the years. :)
Qt covers a lot more than the skin. Also take into account that we are talking about Qt in the times of Harmattan. If you look at the slides you will see that the plan is to use the Qt 4.6 / Qt Mobility (http://labs.trolltech.com/page/Projects/QtMobility) API. It's true that there are many elements that need to be in place, in different platforms and working. But... did I say in the presentation that the Harmattan project is going to be easy to implement?
...cross-platform development over the years. :)
... the plan is to use the Qt 4.6 / Qt Mobility (http://labs.trolltech.com/page/Projects/QtMobility) API. It's true that there are many elements that need to be in place, in different platforms and working. But... did I say in the presentation that the Harmattan project is going to be easy to implement?
I wish in all this talk about "cross-platform", some effort would be put into explaining what does it mean in practice for this context.
On one side, I can understand it in the sense that, sure, the more everybody uses just QT toolkit all over the place (desktop, mobile,...), it's easier for a developer of, say, Ovi Suite for Windows (http://blog.ovi.com/2009/06/25/making-of-ovi-suite-2-0/) to jump over and start developing for Harmattan in the future.
But in terms of UI? Is somebody seriously claiming there's "cross-platform" UI's between desktop and mobile? Just compile away? Especially in terms of having "mainstream users" as goal, which Maemo has according to Quim.
In terms of UI, I can understand (relatively) "cross-platform" QT-based Windows application being ported to Mac OS X with smaller effort (although being truly "Mac" is really really hard).
And I could understand being able to share some UI elements between a future Symbian QT application and future Maemo harmattan QT application. But even there, there's the same thing as in the UI's in the desktop: Windows is not Mac is not Linux, Mac is not Windows is not Linux.
Thoughts?
REMFwhoopitydo
07-05-2009, 01:24 PM
"Quim keynote on Maemo's switch to Qt as the main toolkit "
I hope no one is surprised by this announcement, because they shouldn't be.
as stated above, the big question for me is whether maemo 5 devices will be able to run harmatton?
i am a kde/linux fan, so i applaud maemo's move to QT, but thatb is all the more reason why i don't wish to buy a dead-end GTK+ device.
Andre Klapper
07-05-2009, 02:36 PM
Glib has already (http://opensource.nokia.com/projects/openc/) been ported by Nokia too.
FYI, GLib will still be officially supported and be a part of in Harmattan if I got it right.
Bundyo
07-05-2009, 02:51 PM
Now we only need another switch to Enlightment and we can ditch it... ;)
Sorry, couldn't resist.
FYI, GLib will still be officially supported and be a part of in Harmattan if I got it right.
Of course it is, I meant Nokia have ported it to Symbian :-)
gerbick
07-05-2009, 04:21 PM
Ok... not trying to be ultra-dense here; however am I reading this right that the very next step of Maemo will start the process of dropping GTK+ in favor of Qt and the Qt in Fremantle will only be community supported, much like Mer is community supported?
Just wondering if I got it right.
klausr
07-05-2009, 05:14 PM
"Quim keynote on Maemo's switch to Qt as the main toolkit "
the big question for me is whether maemo 5 devices will be able to run harmatton?
Yes, I think this is an important question, at least for developers. We all have to use new devices for fremantle. I really hope this will not happen for Maemo 6 again. A little bit more compatibility would be a great attraction. Sometimes I love to run some old PalmOS 3.x tools on my Tungsten.
Well, PalmOS has really disatvantages, but on the other side it is very unedifying that one cannot run just two years old tools written for Maemo 3 on Maemo 4 devices.
-Klaus
One of the major reasons Fremantle won't run on Maemo 4 devices is the lack of OpenGL support on those devices, as Fremantle makes use of the clutter OpenGL scene graph library for its user interface. While the N800 and N810 do have OpenGL hardware, the available drivers were never integrated into the OS, and as far as I know, they aren't any good anyway, which is probably why they weren't integrated.
With running Harmatten on the Fremantle device there hopefully won't be any similar problem of the older device lacking a major required capability, at least I can't think of any today.
In fact, if you look at Quim's slides, you'll notice that clutter is being dropped for Harmattan as well. Presumably what is being done with clutter in Fremantle will be done with QGraphicsView and Qt's new declarative UI technology in Fremantle. Qt's graphics stuff has multiple backends, such as software rendering, XRender, GDI and OpenGL, as well as a couple of others relevant to other platforms it supports.
So, the Harmattan desktop, being built using Qt, would presumably still make use of OpenGL acceleration -- but it might not actually require OpenGL support, unlike the Fremantle desktop. This might make it far easier for the Mer people to backport it even to the N800/N810 (but the performance of a desktop targetting a much newer and faster device might not be acceptable on them -- still, I think the switch to Qt is quite possibly great news for N800/N810 owners who don't see themselves buying a Fremantle or Harmattan device).
REMFwhoopitydo
07-06-2009, 04:10 AM
i raised the question of the development life-span of the n910 in two separate threads, principally because of the Intel/Nokia agreement to shift to the 32nm x86 platform due at the end of 2010.
i speculated that this would leave the Omap3 class of devices as development orphans, unattractive as they have neither the long lineage of previous NIT's, nor compatibility with the x86 NITS of the future, and thus would be uninteresting to the 3rd party maemo development community which breathes life into this ecosystem.
the possibility that n900/n910 devices will not have support for Harmatton would be a double blow, as I want to support this new QT/maemo future.
with the greatest of respect to the poster above, i am not interested in n770/n800/n810 devices, as i didn't join the maemo party in their prime, I am looking at the exciting Omap3 platform and wanting the exciting QT/maemo.
if i am left to speculate that the combination of Intel/QT means that the n900/n910 devices will be a development dead-end, then I will persuade myself to skip these devices and hope for a more succesful device class in future, but i do not want to do this because i want to buy an Omap3 NIT as soon as they are available.
it would be very useful if Nokia clarified whether or not Harmattan will come to the n900/n910, as i suspect that many here would happily settle for that at least.
benny1967
07-06-2009, 04:27 AM
it would be very useful if Nokia clarified whether or not Harmattan will come to the n900/n910, as i suspect that many here would happily settle for that at least.
Even if they told you that Harmattan will come to the Maemo 5 lead device.... Would it help? By the time Harmattan will be released, many things may have changed so Nokia needs to adapt their plans accordingly. What then?
You may start developing for Qt under Fremantle (hey, who's that typing on my keyboard? Did I just recommend using Qt???) so you'll have a smoother transition to Harmattan... Or you can rely on the community-provided GTK in Harmattan and use this native toolkit for Fremantle.
Anyway, take what you have and don't expect any information about what will be in 6 months time to be reliable.
It's just too early to discuss about compatibility across Fremantle, Harmattan and corresponding hardware. Some elements for discussion are not public and some elements are not even known by anybody today.
These elements include the state of Maemo 5 Qt bindings compared with the Harmattan API, the existence of a community initiative to maintain GTK+ / Hildon beyond Fremantle, the characteristics of the hardware to be released during the Fremantle and Harmattan releases...
There is even another element, which are the alternatives to the Hildon/Qt native environments. From the announcement this week you can see that OpenGL ES is there, and someone might be interested going that path. Note that we haven't given any details yet about that Maemo API on top of the generic Qt / Qt Mobility API, nor about those supported runtimes mentioned in one of the slides.
The announcement helps developers planning their work for Fremantle having a bit more of knowledge about Harmattan. Let's release Maemo 5 and its related hardware, let's enjoy Fremantle and then let's discuss Harmattan further.
...Let's release Maemo 5 and its related hardware, let's enjoy Fremantle and then let's discuss Harmattan further.
Yes, let's do that! When can I start enjoying Fremantle on its related hardware?
Quim, will Harmattan run on a Maemo 5 device or not?
pycage
07-06-2009, 07:30 AM
This story gives me the impression that Fremantle, from a developer's point of view, is already obsolete even before it was released.
Bundyo
07-06-2009, 08:00 AM
Any work I'm doing now is already obsolete if GTK+ is not at least included in the release in Harmattan. I don't give a damn if it is the lead framework, I just don't want to force any user to install 30-40 MB libs (as is the case with QT now.
Qt in Fremantle will only be community supported, much like Mer is community supported?
Just wondering if I got it right.
Not exactly. This "community" are mostly employees of Qt Software so there will be no official support, bugs will be marked "fixed in Harmattan", etc.
benny1967
07-06-2009, 08:26 AM
This story gives me the impression that Fremantle, from a developer's point of view, is already obsolete even before it was released.
One could discuss the meaning of "obsolete" in this context. Diablo is dead as can be (and has been for quite a while now), and still there are new or updated packages (http://maemo.org/downloads/updated/OS2008/25/). It's out there, so people develop for it, no matter if it's "obsolete".
Fremantle will be out on real hardware, and people will develop for it. The success of the platform in terms of 3rd party applications will be determined by the number of units sold rather than by the fact that Fremantle is known to be the last GTK-based Maemo version.
One could also discuss, of course, the wisdom of Nokia's decision to drop GTK in favor of Qt, but then again... why? It's one of those moments in life where suit and tie beats reason. Sure it's not a wise thing to do, but how could they not do it once they spent all this money on acquiring former trolltech?
Within all these constraints, announcing the move now was the only sane thing to do. They could have chosen not to say anything in order to make developers feel more confident about the future of their GTK-based Fremantle projects.... But in the long run, it's moves like these that earn Nokia trust. (At least I hope so. I really do.)
There is even another element, which are the alternatives to the Hildon/Qt native environments. From the announcement this week you can see that OpenGL ES is there, and someone might be interested going that path. Note that we haven't given any details yet about that Maemo API on top of the generic Qt / Qt Mobility API, nor about those supported runtimes mentioned in one of the slides.
You should not consider Qt and OpenGL-ES as alternatives,
they are rather than supporting each other. OpenGL-ES is used
accelerating lo of the new animated UI effects and if you would like make OpenGL-ES application, Qt can act as wrapper and provide
lot of supporting API's.
I handled this issue in my presentation GCDS but due very poor
network connections here, i have not yet been able to upload my presentation.
GeneralAntilles
07-06-2009, 08:47 AM
i raised the question of the development life-span of the n910 in two separate threads, principally because of the Intel/Nokia agreement to shift to the 32nm x86 platform due at the end of 2010.
One thing is sure, if Nokia moves to x86, they've lost me as a customer and supporter.
flareup
07-06-2009, 09:37 AM
This story gives me the impression that Fremantle, from a developer's point of view, is already obsolete even before it was released.
I'm not a developer, I'm an 'end-user'. And I'm confused.
I have a pc instead of a mac because I can take out hardware components and change them. I liked the idea of 770 and 800 as "open source" because it suggested a wide range of apps and stuff to give the units life.
I fully understand planning years ahead, for hardware that might not even exist, for deals that might or might not be made.
so my confusion here is that 'rover' might come with an OS that will be obsolete within a year and might not run the next one, and that the development work some people are doing now on all the new aspects for that device and OS won't be carried through to the next gen?
Taken with the undeniable fact that 'rover' is really, really late (in terms of both the competition and the lineage of NITs), I'm really confused as to what's going on.
can anone explain in simple terms?
attila77
07-06-2009, 09:52 AM
You should not consider Qt and OpenGL-ES as alternatives,
they are rather than supporting each other. OpenGL-ES is used
accelerating lo of the new animated UI effects and if you would like make OpenGL-ES application, Qt can act as wrapper and provide
lot of supporting API's.
From a developer's personal standpoint - presently 3D is a bit of grey area in Maemo 5. No Qt release I've seen so far (Fremantle betas/extras-devel) included the QtOpenGL module yet, there is some uncertainty about how Clutter comes into play, will we have a game mode, will that have special considerations, etc... The potential is definitely there, but Fremantle is far from ready to start start serious 3D app/game development/porting (like my my favorite QtOpenGL app (http://www.stellarium.org/)) by developers without Nokia hats.
vivainio
07-06-2009, 10:42 AM
One could also discuss, of course, the wisdom of Nokia's decision to drop GTK in favor of Qt, but then again... why? It's one of those moments in life where suit and tie beats reason.
FWIW, I think switching to Qt sounds more like a developer-driven decision than a "suit&tie" matter; many developers find it weird that we are still coding in C in 2009, bindings notwithstanding.
eiffel
07-06-2009, 11:28 AM
... in the long run, it's moves like these that earn Nokia trust ...
You really think Nokia is "showing their cards" here? I don't. I think there's a missing piece of the jigsaw which hasn't dawned on us yet.
I can't image what it is, but I think it will be big. Bigger than "GTK vs. QT"; that's so 5-years-ago. Nokia didn't buy TrollTech and the rest of Symbian just for the fun of it. Big money changed hands and Nokia must have some kind of big-picture plan.
Maybe Symbian and Maemo are being somehow combined. Maybe there's some innovative migration path to bring the Symbian masses to Maemo. And why is Nokia funding a community debmaster? There's gotta be more of a reason behind it than just being nice to us. It's gotta somehow relate to the future product directions.
I hope when the software and hardware bombshell drops it's something awesome rather than something pathetic. It's really hard to call at this point.
Regards,
Roger
eiffel
07-06-2009, 11:29 AM
many developers find it weird that we are still coding in C in 2009, bindings notwithstanding.
Many developers find it weird that people are still coding in C++ in 2009.
Roger.
From a developer's personal standpoint - presently 3D is a bit of grey area in Maemo 5. No Qt release I've seen so far (Fremantle betas/extras-devel) included the QtOpenGL module yet, there is some uncertainty about how Clutter comes into play, will we have a game mode, will that have special considerations, etc... The potential is definitely there, but Fremantle is far from ready to start start serious 3D app/game development/porting (like my my favorite QtOpenGL app (http://www.stellarium.org/)) by developers without Nokia hats.
OpenGL module should be there in extras-devel if not, please
report error to bugzilla. It has been released even before extras-devel in qt4.garage,maemo.org. I had Qt OpenGL-ES2.0
demos running in last spring in ELC in Beagleboard just
based on publicly available tools and libraies.
I had couple of real life demos about using Frematle OpenGL in
reali life game deveopment here in GCDS, hopefully organizers
get presentation videos on line soon.
I did myself port from Desktop OpenGL 2.0 based .obj model
viewer and it was just couple of hours work.
One could also discuss, of course, the wisdom of Nokia's decision to drop GTK in favor of Qt, but then again... why? It's one of those moments in life where suit and tie beats reason. Sure it's not a wise thing to do, but how could they not do it once they spent all this money on acquiring former trolltech?
We are not in static world, to keep our position we need to run.
For mobile device developers view, static box-layout UI's are history.
Just as an example, here in GCDS most of Qt presentations handled
different aspects of animated UI development. We just need to
move to next generation toolkit in some phase, you should see
choice much more between Qt or Clutter than Qt vs GTK+ .
There is still place for static widgets and everything does not need
to have fancy animations . We can also improve lot of traditional
application's usability with good compositing window manager.
...
One could also discuss, of course, the wisdom of Nokia's decision to drop GTK in favor of Qt, but then again... why? It's one of those moments in life where suit and tie beats reason. Sure it's not a wise thing to do, but how could they not do it once they spent all this money on acquiring former trolltech?
Within all these constraints, announcing the move now was the only sane thing to do. They could have chosen not to say anything in order to make developers feel more confident about the future of their GTK-based Fremantle projects.... But in the long run, it's moves like these that earn Nokia trust. (At least I hope so. I really do.)
I guess if I was in the same situation, I'd do the same thing... You could almost see this announcement as "preemptive damage control"... I can't help but feel sorry for the Nokia Maemo developers who worked so hard on this Clutter / GTK based Fremantle and now are going to have to switch everything over to QT for Harmattan...
EDIT: Even if it isn't a "suit and tie" decision, but a developer one, it is still going to be a hard job turning the ship so sharply...
FWIW, I think switching to Qt sounds more like a developer-driven decision than a "suit&tie" matter
This is "suit&tie" decision on high level in terms of Nokia ecosystem. With Qt you can develop programs for navigation units, medium-level phones, smartphones, desktops of all major and many minor OS-es (according to Trolls Qt powers even coffee machines, don't know if Nokia wants to enter this business but who knows ;) )
That doesn't mean that there will be one program which will run on everything (although with Qt this is possible) but one IDE, one language, one documentation for whole company and its cooperators. The only other solution which can provide such flexibility is Java (and Qt has bindings for it - Jambi - so you can write Java programs with Qt).
For some reason Nokia choose Qt instead of Java. Why is matter for another (sub)thread but GTK definitely doesn't cut there.
Switch to Qt isn't matter of Maemo, it is a change of course for whole, multinational, multibillion company. We see only one facet of this decision but there is a bigger picture.
IMO information of this switch in Internet Tables (or whats its name today) is *good* news. Because it means Nokia see some future for this line of products. Letting it go with GTK would mean leaving it in dead waters of company environment for slow death.
...
Maybe Symbian and Maemo are being somehow combined. Maybe there's some innovative migration path to bring the Symbian masses to Maemo.
...
Regards,
Roger
Just stumbled upon this. Symbian plans to use QT and "Direct UI" as the main UI(?) (http://blog.symbian.org/2009/04/30/reviewing-the-release-plan/) in release named Symbian^4 which by extrapolation is finished around end of 2010...
So Qt everywhere and all over.
Yeah, sure, this is obviously the strategy here - being able to tell developers that using Qt, they can target Symbian and Maemo devices with the same codebase. And the motivation behind the Intel/Nokia alliance, from Nokia's side, is making sure that the same apps will also run on Moblin devices. Plus Qt runs on Windows Mobile. It's about attracting app developers by saying "if you use our technology/API, you can deploy your work on all of these devices with relatively little or no extra effort for each individual one."
I think this is a really smart move. Let's face it, on the app side, Nokia is late to the party compared to the iPhone and Android - sure, you could write Symbian apps years before both existed, but the app thing is only really exploding now, and Symbian looks pretty dead compared to the 50k apps for the iPhone and even the 5k apps for Android. With Qt, Nokia might be able to convince developers that their platform is worth an investment of time and effort by them, because it's not limited to only Nokia - Qt also runs elsewhere - and because as a well-established open source solution, it would even outlive Nokia's demise. There's less risk for the developer that way.
As for why they couldn't do that with GTK+: Maybe they could, but Qt does have a portability head start over GTK+ (it's available on more platforms - especially when you're talking commercial-grade quality - and its architecture lends itself better to adding new ones) and it's C++ as is Symbian app development already, so it's a better fit there.
javispedro
07-06-2009, 02:19 PM
Did I miss the conference were Intel said "hey we're going to use Qt too"?
Of course It'll make sense, but don't extrapolate. I
Did I miss the conference were Intel said "hey we're going to use Qt too"?
If you go to the Moblin website and look at their architecture diagram, you'll notice that it does feature Qt, yes: http://moblin.org/documentation/moblin-overview/moblin-core
Moblin is not exclusively using Qt as Harmattan will, but it's involved, yes, and as I wrote above, I imagine Nokia will try to make sure that it is robust enough to play a part in the argument they present to application developers, provided Moblin becomes successful enough to be of interest at all.
richie
07-06-2009, 05:25 PM
The Maemo API in Harmattan will be Qt based and this is all what application developers willing to deal with the native environement will need to care about. But... actually I don't expect the majority of developers willing to deal with native environments by the time Harmattan goes aout, and actually the GTK+/Qt or even C/C++ will sound to far from their interests and concerns.
Hi Quim
Does this mean 'runtimes' are the easiest route in Harmattan? Are the runtimes limited to one type or several? Python and pyqt seem obvious, will python be officially supported?
Rich
Jaffa
07-06-2009, 05:39 PM
And why is Nokia funding a community debmaster? There's gotta be more of a reason behind it than just being nice to us. It's gotta somehow relate to the future product directions.
There's confusion? I thought it was pretty obvious:
Maemo is going more and more mainstream (whether or not it gets there, who knows)
End-user applications make devices these days, but they've always been essential to Maemo devices. Other companies turn this into the ever growing number of app stores (seriously, every other company at JavaOne was announcing a new app store, whether it was a manufacturer like Sony Ericsson, a network like Orange, a software vendor like Sun...)
Quality needs to improve if Extras is going to get turned on by default.
Indeed, didn't the various announcements about the debmaster role make this clear? Why not the same question about a bugmaster, docmaster and webmaster? Everything relates to future products somehow, and improving the quality and sales of those devices.
The PyQt situation is interesting because unlike Qt, it's not LGPL yet. I'm sorta expecting Nokia to buy Riverbank any minute now, though.
it's C++ as is Symbian app development already, so it's a better fit there.
Yeah, sticking one weird C++ dialect on top of another (exceptions, anyone?) is going to work really well...
It's just too early to discuss about compatibility across Fremantle, Harmattan and corresponding hardware.
Sure. Let me flip that question around: is Nokia willing to provide the essential support (you know, enough to boot, draw stuff on the screen and have network connectivity) for running a (community-supported) Hildon-based Mer on Harmattan devices?
Diablo is dead as can be (and has been for quite a while now), and still there are new or updated packages (http://maemo.org/downloads/updated/OS2008/25/). It's out there, so people develop for it, no matter if it's "obsolete".
That's likely to change once third-generation hardware is out. How many new packages do you see for the 770 (Hacker Editions aside)?
Within all these constraints, announcing the move now was the only sane thing to do.
No, the sane thing to do would be to provide a transition path. At least one of the two GUI frameworks should be officially supported on both releases.
They say they can't do that because of lack of resources, but at the same time they admit they'll have to rewrite everything that draws on the screen to C++/Qt which is orders of magnitude more work. Something does not quite compute there...
One other thing to consider: if the "community" isn't able (or willing - unpaid volunteers have even fewer resources available) to pick up the slack in time for the Harmattan release it would mean that most existing apps simply won't work on Harmattan devices. That will hurt both sales and developer adoption, and Nokia should care about those.
One thing is sure, if Nokia moves to x86, they've lost me as a customer and supporter.
Of all the things they are/could be doing wrong this is your dealbreaker? As long as performance and power management are comparable who cares if the architecture is ARM or x86 (or MIPS, PPC, SPARC, whatever)? Sure, current x86 chips don't have the power management features of current ARM chips, but there's nothing in the instruction set that dictates that, it's simply that they have been targetting the PC market so far.
Oh, and for all their faults Intel is much more open than ARM/TI.
vivainio
07-07-2009, 04:44 AM
One other thing to consider: if the "community" isn't able (or willing - unpaid volunteers have even fewer resources available) to pick up the slack in time for the Harmattan release it would mean that most existing apps simply won't work on Harmattan devices.
Those who want to be able to code in Gtk for phones certainly should be motivated enough to get the community port of hildon working on Harmattan, since that's going to be the only phone allowing that in the first place. If the community doesn't care enough, that would signal that it's not that important in the first place.
It shouldn't be a gigantic effort, you can basically get the fremantle version of hildon and remove the clutter-specific code. Perhaps Nokia could fund this enough to get it kickstarted, and leave the maintenance/improvement for the community.
Those who want to be able to code in Gtk for phones certainly should be motivated enough to get the community port of hildon working on Harmattan,
It's not just a matter of motivation. Someone who is able to code an app in Gtk+ doesn't necessarily have the skills to hack Gtk+ itself. Also, the switch involves all of Hildon, ie a lot more than just Gtk+ - what about control panel, home & statusbar applets, input methods, and libraries like libhildonmime & libhildonnotify? Consider that their Harmattan replacements most likely won't have C bindings.
It shouldn't be a gigantic effort, you can basically get the fremantle version of hildon and remove the clutter-specific code.
Which means Fremantle apps that utilise that code won't run, ie more fragmentation.
Perhaps Nokia could fund this enough to get it kickstarted, and leave the maintenance/improvement for the community.
That looks like exactly what they are doing, with Fremantle being the kickstart stage.
It shouldn't be a gigantic effort, you can basically get the fremantle version of hildon and remove the clutter-specific code. Perhaps Nokia could fund this enough to get it kickstarted, and leave the maintenance/improvement for the community.
Clutter is used in Frematle mostly in Hildon desktop compositing
window manager, it is not used in applications.
The things need to be done are mostly same that we needed to do
for Hildonized QT. Adapt Hildon to Harmattan Styles and Input
method.
attila77
07-07-2009, 05:50 AM
Sure, current x86 chips don't have the power management features of current ARM chips, but there's nothing in the instruction set that dictates that, it's simply that they have been targetting the PC market so far.
Not really. There have been low power/embedded x86 versions quite a while now, even from vendors other than Intel (see geode). x86 (like ARM) isn't JUST an instruction set, it's a platform and brings quite a bit of baggage (which you need to carry on to be compatible), and instruction sets are just a facet of that. The two ways they can overcome this is that they break compatibility (not really x86 then, is it?), or make fabrication improvements WAY beyond any ARM licensee (not gonna happen in years).
Not really. There have been low power/embedded x86 versions quite a while now, even from vendors other than Intel (see geode).
Yeah (my favourite being VIA), but they don't go far enough for "mobile" use yet. They concentrate on making the chip more efficient while leaving it and the associated "chipset" running all the time whereas an OMAP can switch off most parts when they are not used, getting similar idle consumption rates as "suspend to RAM" would on an x86. Oversimplifying a bit (yes, I know about C-states, P-states etc) but all current x86 chips eat a lot of juice unnecessarily even when they're doing nothing.
The two ways they can overcome this is that they break compatibility (not really x86 then, is it?)
There might be (I honestly don't know) implicit assumptions that could break things like Windows drivers on an aggressively power-saving chip, but Linux should be ok or at least fixable.
They say they can't do that because of lack of resources, but at the same time they admit they'll have to rewrite everything that draws on the screen to C++/Qt which is orders of magnitude more work. Something does not quite compute there...
They have to rewrite only low level stuff. User space apps written for Qt in Fremantle should work without many problems in Harmattan.
I think this announcement means for developers: you want stable platform now: use GTK+ for now and face uphill battle later with unsupported foundations or rewriting of your program in Qt.
But if you plan with few years ahead you should start already with Qt. Yes, this will be unsupported officially now but you can use Fremantle as beta stage and have solid release with Harmattan in 2010.
Note that it is in sync with roadmap for Symbian^x (recently linked here) where also only in 2010 fully new version with Qt as primary user space language will be released. IMO every puzzle nicely fits in.
They have to rewrite only low level stuff. User space apps written for Qt in Fremantle should work without many problems in Harmattan.
Uhmm... you are ignoring all the Nokia userland stuff. They will have to rewrite every single hildon user-space app/applet in C++/Qt. That includes the file manager, media player, image viewer, pdf reader, rss reader, calculator, clock, sketch, terminal, application manager, backup/restore, connection manager, internet call, chat, contacts, modest, microb, control panel, statusbar and desktop applets, the whole shebang.
Additionally, all the "partner" applications will have to be rewritten as well: skype, gizmo, wayfinder etc. I'm guessing the Mozilla (fennec, not microb) people may not be too happy to switch to Qt either.
So that's why it takes one more year to get fully supported Qt edition of IT. Mozilla, well who needs them with QtWebKit?
vivainio
07-07-2009, 08:08 AM
They will have to rewrite every single hildon user-space app/applet in C++/Qt. That includes the file manager, media player, image viewer, pdf reader, rss reader, calculator, clock, sketch, terminal, application manager, backup/restore, connection manager, internet call, chat, contacts, modest, microb, control panel, statusbar and desktop applets, the whole shebang.
Luckily, Nokia will be footing the bill for those. Considering that it would have happened anyway at some point (in order to not completely "orphan" Maemo from the other stuff they are doing, e.g. with Symbian), it's better to do it now than 2 years down the road.
javispedro
07-07-2009, 08:27 AM
Again, no need to worry. All those pesky applications will be deprecated and only MicroB will ship in the default rootfs.... the rest will be "community" maintained. :D
GeneralAntilles
07-07-2009, 08:41 AM
As long as performance and power management are comparable . . .
Thing is, this is precisely what they wont be.
sjgadsby
07-07-2009, 08:49 AM
Does this mean 'runtimes' are the easiest route in Harmattan?
I wonder if Nokia WRT might be significantly expanded, enhanced and brought to Maemo by the time Harmattan becomes a serious application development target.
REMFwhoopitydo
07-07-2009, 09:04 AM
Uhmm... you are ignoring all the Nokia userland stuff. They will have to rewrite every single hildon user-space app/applet in C++/Qt. That includes the file manager, media player, image viewer, pdf reader, rss reader, calculator, clock, sketch, terminal, application manager, backup/restore, connection manager, internet call, chat, contacts, modest, microb, control panel, statusbar and desktop applets, the whole shebang.
Additionally, all the "partner" applications will have to be rewritten as well: skype, gizmo, wayfinder etc. I'm guessing the Mozilla (fennec, not microb) people may not be too happy to switch to Qt either.
skype for one, always has been a native QT app as far as i know.
Luckily, Nokia will be footing the bill for those.
Yes, but given the magnitude of the task and the repeatedly cited lack of resources it's going to be a rush job. How many features (or entire apps) will be dropped? How many new bugs will be introduced? How many Fremantle "Official Applications" bugs are likely to be even looked at?
Until last week we were given to understand that both frameworks would eventually coexist, so there would be no need to throw away the baby with the bathwater. Even if Hildon absolutely positively must be dropped, a sane transition plan (ie one release with both present and supported) wouldn't necessitate would give more time to everyone to move over gracefully. The current plan is really a bonehead maneuver - not even Apple does things like this!
skype for one, always has been a native QT app as far as i know.
Is it? Dunno, I never installed it :-) The point still stands though, there are all sorts of "non-free" applications whose authors might not be willing to rewrite from scratch in a different language.
A related issue is ports of existing upstream apps (which for obvious reasons are extremely unlikely to even consider switching). Goodbye Pidgin, Gpodder, Abiword, Gnumeric and so on unless/until "the community" manages to port Hildon to Harmattan. Anidel has already indicated (http://lists.maemo.org/pipermail/maemo-users/2009-July/013905.html) that we'll lose Xournal, and I can't blame him.
attila77
07-07-2009, 09:29 AM
Even if Hildon absolutely positively must be dropped, a sane transition plan (ie one release with both present and supported) wouldn't necessitate would give more time to everyone to move over gracefully.
What do you mean, more time ? We're talking about things so much in the feature that even the year is an estimate and releases that follow stuff that itself is so new that has not been released yet... Also, Fremantle IS the transitional release you are missing - it seems it will have solid Qt support even though the default toolkit is GTK. The Qt maneuver was pretty certain once Nokia bought Qt (from that point on, it would have been silly NOT to push Qt). Whether that will cause the 5 step program to become a 6 step, we have yet to see (e.g. will Harmattan manage to nail Qt first time on and be the real deal, or will there be an additional release that will finalize Maemo incubation for the general public).
deadmalc
07-07-2009, 09:30 AM
Given the current roadmap (http://wiki.maemo.org/Task:Maemo_roadmap/Harmattan) just specifies "after Fremantle" and given that hasn't even been given an official release date yet, aren't we all jumping the gun a little?
My assumption would be that Fremantle is there to allow both frameworks to co-exist and start the migration of "non-official" apps to Qt and then Harmatten will be the migration of "official" apps?
If it's any slower aren't we likely to be on QT 6 ? ;-)
javispedro
07-07-2009, 09:31 AM
Indeed. While I personally applaud the QT switch, this is two API breaks we're talking about (both of them within a few years span).
BTW, I believe this has not been posted here yet:
http://live.gnome.org/GObjectIntrospection/GObjectConsume
I like the way it sounds. Maybe Nokia is using something like that? AFAIK they're going to continue using glib, so it may make sense. Who knows.
What do you mean, more time ?
Not having to rewrite the world all at once in a hurry.
Also, Fremantle IS the transitional release you are missing - it seems it will have solid Qt support even though the default toolkit is GTK.
Fremantle: Nokia-supported Hildon / community-supported Qt.
Harmattan: Nokia-supported Qt / community-supported (maybe) Hildon
I don't see a smooth transition at any point. That may work for a hobbyist project, but commercial software developers will laugh at your face if shown such a roadmap. At best they will completely skip Fremantle and wait and see if Harmattan piques their interest.
The Qt maneuver was pretty certain once Nokia bought Qt (from that point on, it would have been silly NOT to push Qt).
Sure, and just to be clear: I don't mind (and even welcome) Qt. My objections are to the simultaneous and disruptive drop of Hildon with no transition period. The standard practice in such cases is to have one or more releases with both the old and new frameworks available, but the old marked as deprecated.
nilchak
07-07-2009, 09:48 AM
If the Qt route means that both Symbian as an application platform and Maemo as a application platform support a common language QT - then that is a boon - in the sence apps written for one platform can be easily ported to symbian platform with much more minor changes.
The cross-platform nature in the mobile sphere itself is a huge boon. Name one language now in the mobile world where you can develop an application and make it work on another mobile platform ? NONE.
(Of course not counting Java) :p
So this move seems more enticing from a developer perspective.
And getting a developer momentum is I believe the most critical thing in establishing a mobile platform as a standard.
Look where Zaurus (with its Qtopia), OpenMoko and Moto Linux got to without a big developer community behind it.
Even Maemo developer community is a niche community we have to agree.
So any effort to encompass a bigger development world is worth a try I believe.
attila77
07-07-2009, 09:58 AM
Fremantle: Nokia-supported Hildon / community-supported Qt.
Harmattan: Nokia-supported Qt / community-supported (maybe) Hildon
The standard practice in such cases is to have one or more releases with both the old and new frameworks available, but the old marked as deprecated.
But wait, you just wrote it up there. Harmattan is Qt, with GTK/Hildon marked as deprecated (it's still there but don't build empires on it). How good/serious that community support will be is another issue. Quim said clearly they don't have the resources to maintain both in equal status. I'd go as far and say it would be downright silly to have both in a pretend-equal status, even for one release, when you know that one of those is going out the door (that's why you have the deprecation stuff in the first place).
benny1967
07-07-2009, 10:01 AM
My objections are to the simultaneous and disruptive drop of Hildon with no transition period. The standard practice in such cases is to have one or more releases with both the old and new frameworks available, but the old marked as deprecated.
I can see your point and in fact even agree that this is what should have happened in an ideal world.
OTOH: I am not yet certain about the quality of the "community supported" versions of Qt/GTK. If they are both rock solid, then you get what you want, don't you? At least wo releases in a row that feature both toolkits.
You may even get GTK-support long after Harmattan... Who says GTK is deprecated? If it's there in extras, it can as well be there to stay.
Pulling it in as a dependency may sound a nightmare on current hardware, but who knows how much memory we will have available on Harmattan devices?
So a lot depends on the quality of the "community supported" versions of both toolkits, especially on the quality of GTK in Harmattan and later versions. It can go all wrong... or it could be very easy. What I'd hope for is that one of the other players who currently seem to hesitantly watch Maemo grow (Intel? Ubuntu? ...?) find it interesting enough to get their hands dirty here. "Community supported" doesn't necessarily mean that members of this forum need to do it on a rainy weekend.
But wait, you just wrote it up there. Harmattan is Qt, with GTK/Hildon marked as deprecated (it's still there but don't build empires on it).
Well, no:
GTK+/Hildon won't be used by the applications shipped with Harmattan out of the box and therefore won't be pre-installed. When we say that GTk+/Hildon will hopefully be there as community supported we really mean that. If all things go well developers interested in these libraries would find them in Extras, just like they are finding e.g. the Python bindings there now.
It all depends on someone picking up the ball and having sufficient time and skill to manage a decent port in time for the Harmattan release.
The only somewhat realistic development path for new apps (unless you want to support Diablo) is to go with Qt and hope any bugs (https://bugs.maemo.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__all__&product=Qt&content=) you come across are not showstoppers. But if I was a commercial developer I would be dropping the platform for the next couple of years until they get their act together.
gerbick
07-07-2009, 11:36 AM
skype for one, always has been a native QT app as far as i know.
Then why no updates since 2007? Again... no compelling reason(s) based on prior experience to continue supporting these decisions that are based on... "logic".
A related issue is ports of existing upstream apps (which for obvious reasons are extremely unlikely to even consider switching). Goodbye Pidgin, Gpodder, Abiword, Gnumeric and so on unless/until "the community" manages to port Hildon to Harmattan. Anidel has already indicated (http://lists.maemo.org/pipermail/maemo-users/2009-July/013905.html) that we'll lose Xournal, and I can't blame him.
There is no need rewrite whole application, only the UI part.
Re-engineering UI is mandatory issue if you are porting desktop
application and like to make your application mainsteream mobile
application. Do you think that iPhone applications are just made
by compiling Macintosh desktop applications without doing anything
to UI ?
If you would like mane modern up to date mobile UI you should
use either Qt or Clutter and that mens re-engineering the UI layer.
There was no choice not re-engineer but choice of what toolkit
to chose and Nokia chose Qt.
If application developer is not willing to design mobile UI then
application is doomed to be niche audience product.
There is no need rewrite whole application, only the UI part.
This is not really my area of expertise, but AFAIK there's no easy way to bolt a Qt UI onto a pre-existing plain-C application. If there is I'll be more than happy to be corrected :-)
conny
07-07-2009, 01:30 PM
Well, generally I don't have strong feelings about using Qt or Gtk+ for new applications. But switching toolkits now will be very challenging for Maemo, the community and Nokia. Amongst others I see the following problems.
* Qt in Fremantle doesn't look like Gtk/Hildon in Fremantle. It looks much more like Gtk/Hildon in Diablo [1 (http://lists.maemo.org/pipermail//maemo-developers/2009-May/019161.html)] [2 (http://blogs.forum.nokia.com/blog/kate-alholas-forum-nokia-blog/2009/03/02/qt4.5-for-maemo-5-fremantle-sdk)]. So Fremantle will not be the right place to already start with Qt.
* Gtk/Hildon community support will (probably) suck. We (the community) are barely enough developers to produce great applications. No offense meant, but we have about 500 apps and many of them are simple ports or no longer maintained. Others are still young and developer time is mostly rare.
If you then look on how much time the Hildon/Gtk (full time) hacker are spending to get the code into shape for Fremantle, I don't see how the community can produce a Harmattan Hildon/Gtk which looks and feels good.
Maybe it will work that we'll have Fremantle-Level Hildon/Gtk support, but what about the new features and a new look of Harmattan?
If development is like it is now, then no one will even know how Harmattans Qt is exactly looking before the final release. How should the community come up with something that will integrate regarding look and feel?
* As I wrote earlier we are only few developers but still we have a couple of hundreds of applications to port. Now some people here write that you only have to rewrite the UI layer. Well, for some applications this might be true, but there are also apps that are heavily depending on Gtk. Porting those apps will basically mean rewriting. If I check Conboys code, I think I'll have to rewrite about 70% of the code. Probably it will be easier to start all over again. Now that's not really a good motivation. Especially it's not a good motivation for introducing new features into the Fremantle/Gtk version now.
* Write once run everywhere will also not work with Qt. Desktops and Phones are just too different, so porting the UI is still the same story as today with Desktop-Gtk and Hildon.
* Also it was mentioned that Gtk+ is obsolete and Clutter or Qt should be used anyways.
Well, first Clutter is no replacement for Gtk+ nor Qt. Second, Gnome 3.0 will still be based on Gtk+ and IMO it's not looking obsolete. And third (very personal) I don't see the need for animations and 3d effects when writing an email or doing a phone call. And animations like window switching have nothing to do with the toolkit.
* Last but not least, we loose the complete knowledge that was build up within the last years regarding C, Gtk+ and Hildon. I guess that also means loosing people...
I think for me personally the main problem will be motivation. I'm not really motivated anymore to put energy into a project that I can mostly throw away in a year or two. And I'm not motivated to switch to Qt now, because right now Qt pulls in a lot of dependencies and it doesn't look good on Fremantle.
Dilemma :confused:
nilchak
07-07-2009, 01:32 PM
Then why no updates since 2007? Again... no compelling reason(s) based on prior experience to continue supporting these decisions that are based on... "logic".
Maybe beacause supporting a GTK based app is takes more resource for them as they are native QT based ?
Again, if they didn't support GTK app, they might also not support a QT based app either.
This is in no way related to Maemo moving from being GTK based to being QT based. Hopefully it will be the other way around - once Mameo is Qt based, Skype will have more frequent updates (at least on Par with the desktop linux version) .
But switching toolkits now will be very challenging for Maemo, the community and Nokia.
That's because the world at large is still using the (http://en.wikipedia.org/wiki/C_%28programming_language%29) wrong (http://en.wikipedia.org/wiki/C%2B%2B) tools (http://en.wikipedia.org/wiki/Java_%28programming_language%29) for the job. If they used the right one (http://wiki.freepascal.org), switching toolkits would be just a configuration option ;)
(just partially kidding, it wouldn't work for the tablet).
And third (very personal) I don't see the need for animations and 3d effects when writing an email or doing a phone call. And animations like window switching have nothing to do with the toolkit.
I agree, but, hey, preteens love these things....
Goodbye Pidgin, Gpodder, Abiword, Gnumeric and so on
But welcome kopete, kword, kcalc, etc.
I suppose it will be much easier to make KDE apps running smoothly on Harmattan then port Hildon apps.
While there will be problem to replace apps created from the start as tablet tools (eg. seqretary, conboy) replacement of desktop-derived programs should be much simpler.
But welcome kopete, kword, kcalc, etc.
Not really, as these also depend on a large bunch of KDE libs which (even if someone ported them) might not fit on the root filesystem.
attila77
07-07-2009, 03:58 PM
Again, if they didn't support GTK app, they might also not support a QT based app either.
IMO the guarantee is that they paid far more money just to get Qt than they ever did spend on GTK coders and development. By owning ex-Trolltech, now they have a far more vested interest of keeping it (and applications based on it) alive and kicking. Also, do not underestimate what owning actual upstream (!) means. In fact, I'd bet serious money that even considering the demise of Qtopia/Qt Embedded, the next Qt versions will somehow find new love for mobile devices :)
Not really, as these also depend on a large bunch of KDE libs which (even if someone ported them) might not fit on the root filesystem.
Hmm, if they can port KDE Plasma on S60 device it shouldn't be so hard to do it for Maemo?
http://www.youtube.com/watch?v=9ni_6qTwj-Y
Hmm, if they can port KDE Plasma on S60 device it shouldn't be so hard to do it for Maemo?
http://www.youtube.com/watch?v=9ni_6qTwj-Y
That's just a "widget" (in the web run-time sense) engine, not a KDE application. It probably has minimal (if any) KDE-specific dependencies.
Fremantle will have a WRT too I think.
And if you absolutely must have KDE apps, there's always the chroot way ;-)
GeneralAntilles
07-07-2009, 07:32 PM
I agree, but, hey, preteens love these things....
Well done effects can provide you with important information and UI clues more effectively than simple static UIs ever can.
As with anything, tools are nothing more than that, some people use them well and some people don't, and, unfortunately, doing this well is a skill many companies seem to lack, but from the Fremantle screencasts I've seen so far it looks pretty promising (Modest just looks slick).
Fremantle IS the transitional release you are missing - it seems it will have solid Qt support even though the default toolkit is GTK.
That might be true if Nokia had targeted Fremantle (Maemo 5) at the current Maemo 4-sporting devices (N8x0-series).
As an existing Nokia/Maemo customer I really don't see much "transitionality" in this move, especially when it means that even the developers of existing (GTK+) apps will be encouraged to leave the current (hardware & software) platform as soon as possible.
Are they still selling those N810s...? :rolleyes:
Architengi
07-07-2009, 08:18 PM
> > 2) App compatibility between OS versions and sub-versions (and devices)
#2 will always be a problem on every device, and from what I've seen, it will be a problem moving to the N900 (Maemo 5). And it sounds like there'll be another break for the next OS (Maemo 6), when they move to the QT toolkit.
This is only Nokia problem, they simply don't care.
They simply say all the existing applications of Maemo 3, 4 and 5 made with Hildonized Gtk+ will stop working in Maemo 6.
This is simply un-excusable as a rationale direction and approach. Looks like dictatorship to me. "we don't care about your old software".
Why is so hard to keep both Qt and Gtk+? Stuborness? I know there is or can be created a small reason for everything, but if you want to say "the end user is our boss" then you have to make it easy for him, not very hard. The same for programmers, they will leave the platform if the direction changes that much dramatic.
Architengi
07-07-2009, 08:30 PM
Nokia missed a lesson.
I don't know if American culture where you can return what you bought to the store even after 6 months (like Costco) - so the culture that say "we really want to satisfy the customer like the customer is our boss" - compared to European culture - makes the diffrence, but:
1) unless Nokia will not make OS upgrade that is compatible
2) unless Nokia will not renounce on the practice of "secret" device API instead of public APIs and plug and play
3) unless Nokia will not go in zig-zag directions with the OS supported (the s80 and s90, superior to s60 were abandoned, s60 is kind of crappy for upgrade - installed applications will be lost, Maemo was kind of abandoned for about 2 years because no new device was released with it, and now they slowly restart working on a device for it)
4) unless Nokia will not keep the old GTK+ API in the system along with Qt, to let the users be able to use old Maemo 3, 4 or 5 applications
this sounds to me a wrong strategy, and there are many programmers, power-users and analysts out there saying Nokia is doomed in the smartphone market, facts and figures show anyways Nokia lost almost half of the market share they had (they had 49% in 2006 and at the end of 2008 they had only 31%).
javispedro
07-07-2009, 09:14 PM
s60 is kind of crappy for upgrade - installed applications will be lost
I seriously doubt points like that make any difference at all in market quota.
All that's needed is marketing, marketing, and more marketing, and promoting "whatever the trendy reviewers think is the-nice-feature-I-couldn't-live-without-today-even-though-I've-been-living-without-it-for-years" (which these days seem to be:
a IBM Model M quality keyboard on the phone,
a low quality capacitive touch screen instead of a high quality resistive one which also works with greasy fingers,
removing ALL of what is left from good old tested for years user interfaces and replacing them with 2 or 3 Homer Simpson-sized buttons,
and, of course, a webpage-totally-filled-with-useless-but-expensive-applications a.k.a. "quantity > quality app store"
).
Also, plainly discarding all of its current Maemo user base and developer base will not damage Nokia at this point, so that's why I believe they made a good company decision by switching to Qt.
Of course, as both user and developer, it bothers me. But hey, I was just reading page 2 of the Gtk+ manual. There's still time to download Qt's manual instead.
That's just a "widget" (in the web run-time sense) engine, not a KDE application. It probably has minimal (if any) KDE-specific dependencies.
As a KDE developer: That's incorrect. While the Plasma desktop shell does support widgets "in the web run-time sense" (it has support for Apple Dashboard widgets, which are written in HTML/CSS and JavaScript), the video in question shows native Plasma widgets, which are not web documents (i.e. UI elements, layout management, etc., are not done by a web content engine, but with Qt technology). They're written in C++, JavaScript, Python or other languages bindings exist for. Of course, being Qt, it's trivial to throw a WebKit element into a Plasma widget and show some web content in it, however.
Plasma requires KDE's libraries to run in addition to Qt, and various things shown in the video make use of technology found in those libraries - the freedesktop.org icon naming spec-compliant icon loading and the implementation of the calendar system, for example. In fact, Plasma's own library (which is also used by applications other than Plasma, for example the popular music player/manager Amarok) is part of kdelibs as well.
If you take a look at the info box for the video on YouTube, you will find a link to the sources in KDE's SVN repository there, including the S60 port of kdelibs. It's not a complete kdelibs, but I wouldn't really characterize it - or Plasma's dependencies on kdelibs - as minimal.
pycage
07-08-2009, 03:11 AM
Nokia appears to have a history of breaking stuff without having a clear goal with Maemo.
OS 2005 -> OS 2006: switched from ARM to ARMEL, all applications had to be recompiled, no finger-friendly UI
OS 2006 -> OS 2007: (N800) switched from OMAP1 to OMAP2, this was necessary and not too tragic, since OMAP2 could execute OMAP1 code, many apps had to be recompiled because of API breakage though. mix of finger-UI and stylus-UI with poor autodetection
OS 2007 -> OS 2008: again much had to be recompiled once again. no more finger/stylus-autodetection. mix of finger-UI with stylus-UI
OS 2008 -> Diablo: smooth transition, wow!
(so far, API breakage was OK because maemo was not mainstream. the next step enters mainstream market, though)
Diablo -> Elephanta: dropped. time is running out. Nokia faces tough competition. No point in concentrating on the NIT devices any more.
Diablo -> Fremantle: OMAP2 -> OMAP3, API breakage, HIG (human interface guidelines) breakage. finger-UI. Many apps have to be redesigned for the new UI guidelines.
Fremantle -> Harmattan: toolkit switch from Gtk to Qt, switching from C to C++ as the default language. Many apps will have to be rewritten! Possibly switching CPU architecture from ARM to x86. Total breakage, total disaster. Once downloaded or paid apps from the "app store" will no longer work.
Nokia seems to be struggling real hard with iPhone and Android competition. The N900 could be a year too late for catching up. I'm still a fan of the NITs and am looking forward to the N900, but slowly I begin to lose faith in maemo, and the latest news don't help rebuilding faith.
If you take a look at the info box for the video on YouTube, you will find a link to the sources in KDE's SVN repository there, including the S60 port of kdelibs. It's not a complete kdelibs, but I wouldn't really characterize it - or Plasma's dependencies on kdelibs - as minimal.
I stand corrected. That (porting a non-trivial chunk of kdelibs to S60) is really impressive then :-)
the s80 and s90, superior to s60 were abandoned, s60 is kind of crappy for upgrade
While I don't necessarily disagree re: S60, a vastly improved version of the S90 (http://www.youtube.com/watch?v=9ni_6qTwj-Y) UI (aka Hildon) lives on in Maemo. Ok, as we just found out its days are numbered but it's there right now if you want it.
OS 2005 -> OS 2006: switched from ARM to ARMEL, all applications had to be recompiled
That's ok, ABI breaks happen sometimes and this one had several (http://wiki.debian.org/ArmEabiPort) benefits & was pretty much a necessary move since upstream compilers, distributions etc were moving to EABI. Most other ARM platforms had to go through the same transition.
OS 2008 -> Diablo: smooth transition, wow!
Both Chinook (aka Maemo 4.0) and Diablo (Maemo 4.1) are "OS2008". As the version numbering suggests there shouldn't be any major API or ABI breaks.
Fremantle -> Harmattan: toolkit switch from Gtk to Qt, switching from C to C++ as the default language. Many apps will have to be rewritten! Possibly switching CPU architecture from ARM to x86. Total breakage, total disaster.
In most ways that matter we could consider Harmattan a new platform. Sure, many of the low and middle level components remain, but it's been hinted (http://talk.maemo.org/showpost.php?p=302126&postcount=22) that we would access them via "Qt Mobility" wrappers for cross-platform compatibility reasons so for all intents and purposes they are different. Besides, those components also there in (for example) ALP or Openmoko and we don't go around calling them Maemo.
Well done effects can provide you with important information and UI clues more effectively than simple static UIs ever can.
Maybe, but when you learn your way around the UI, the novelty factor wears off, the effects become annoying and you turn them off (provided somebody didn't decide she knows better and doesn't let you turn them off).
As with anything, tools are nothing more than that, some people use them well and some people don't, and, unfortunately, doing this well is a skill many companies seem to lack, but from the Fremantle screencasts I've seen so far it looks pretty promising (Modest just looks slick).
Well, it doesn't matter if it looks slick but it doesn't do its job well. Claws looks like sh*t on the tablet, but it actually works.
for me it's actually ui nirvana, but for those looking for effects, animations, big icons and whatever it probably looks like sh*t.
This is not really my area of expertise, but AFAIK there's no easy way to bolt a Qt UI onto a pre-existing plain-C application. If there is I'll be more than happy to be corrected :-)
That depends a lot of what your application is doing. In easiest
case, you can refactor UI with Qt designer in couple of days
and leave the actual application logic un touched.
In worst case if your application is about 100% UI then thing is
different. There is no magic mixing C and C++ together.
We have started announcing changes on Harmattan even before releasing Fremantle final precisely to have enough time to discuss and make the right steps. Nobody is asking current Maemo application developers to switch to Qt, they better concentrate on Fremantle in the way that pleases them better.
Also nobody is asking these app developers to go and maintain the toolkit in Harmattan. The announcement was done in front of an audience of platform developers including plenty of GNOME contributors and the GTK+ and Hildon developers.
Technically there shouldn't be many problems having the Fremantle Hildon/GTK+ libraries coexisting with the Harmattan application framework based on Qt, thanks to keeping the same middleware. Getting these Fremantle Hildon apps 'as is' in Harmattan shouldn't be a big deal.
The Harmattan API and UI will bring more things and having GTK+ apps taking all the new thing is surely a more complicated task. But this is one of the things the community and the developers interested can decide: prioritize the alignment with GNOME or with Maemo, or find ways to satisfy both.
GeneralAntilles
07-08-2009, 08:33 AM
Maybe, but when you learn your way around the UI, the novelty factor wears off, the effects become annoying and you turn them off (provided somebody didn't decide she knows better and doesn't let you turn them off).
Well done is the operative term here, and you're clearly not getting my point. But continue on with your bias against composited UIs. It's of little matter to me.
nilchak
07-08-2009, 10:16 AM
Maybe, but when you learn your way around the UI, the novelty factor wears off, the effects become annoying and you turn them off (provided somebody didn't decide she knows better and doesn't let you turn them off).
A UI is as it says an interface to interact with the software.
Having special effects doesn't necessarily mean just cheap thrills. If its done with tought and good design, it actually enhances the user experience - not in the "Wow that is cool sliding effect", but in reducing the amount of time it takes for an average user to interact usefully to do a task.
Or it increases the choices in how you can accomplish something.
Please don't equate UI effects to only graphical gee-whiz effects. Its really more than that.
Claws having multiple panes unlike many other apps is itself an UI effect so to speak. Similarly a sliding window to reveal additional info is also a effective UI design. Just because it slides gracefully doesn't mean its of no use.
Having special effects doesn't necessarily mean just cheap thrills. If its done with tought and good design, it actually enhances the user experience - not in the "Wow that is cool sliding effect", but in reducing the amount of time it takes for an average user to interact usefully to do a task.
[.....]
Similarly a sliding window to reveal additional info is also a effective UI design. Just because it slides gracefully doesn't mean its of no use.
Well, that's contradictory: if it slides gracefully it will take more time to show the information than just popping it up instantly.
The special effect, while nice, will increase the time, not reduce it.
Edit: and having the information already visible in the first place will further reduce time.
Well done is the operative term here, and you're clearly not getting my point. But continue on with your bias against composited UIs. It's of little matter to me.
I have nothing against composited UIs, but, yes, I have a bias against form over function (or, worse, form to mask the lack of function).
Jaffa
07-08-2009, 10:51 AM
[.....]Well, that's contradictory: if it slides gracefully it will take more time to show the information than just popping it up instantly. The special effect, while nice, will increase the time, not reduce it.
However, the key point was "interact usefully". Sure, in terms of the photons hitting the retina, immediately popping up is quicker. However, an animation can give the brain context which makes it easier to parse the new information which it's seeing, which makes it quicker to "interact usefully", as less time is spent working out WTF just happened :-)
nilchak
07-08-2009, 10:55 AM
[.....]
Well, that's contradictory: if it slides gracefully it will take more time to show the information than just popping it up instantly.
The special effect, while nice, will increase the time, not reduce it.
Edit: and having the information already visible in the first place will further reduce time.
I think you are confusing reducing time to display a window vs reducing overall time to accompish a task - bring down menus and sub menus etc.
And info doesn't just show up. You still have to bring up a window to show it sliding or non-sliding.
I don't want to take this argument to the level of screen display and window pop-ups really, cause UI design is more than that. And if you can't grasp that, then there is no point is debating "time to slide a window vs time to open a window" kind of small talk.
However, an animation can give the brain context which makes it easier to parse the new information which it's seeing, which makes it quicker to "interact usefully", as less time is spent working out WTF just happened :-)
Ok, that's can be useful the first n times you look for that information. Then your brain has supposedly adapted and knows what kind of information is there, so the animation gets in the way.
At first the animation helps you, over time it slows you down.
It's like memorizing often used functions: selecting the option from a menu is a big help when you're starting to use an application, over time it's just quicker to use the keyboard shortcut.
sachin007
07-08-2009, 11:43 AM
Ok, that's can be useful the first n times you look for that information. Then your brain has supposedly adapted and knows what kind of information is there, so the animation gets in the way.
At first the animation helps you, over time it slows you down.
It's like memorizing often used functions: selecting the option from a menu is a big help when you're starting to use an application, over time it's just quicker to use the keyboard shortcut.
And those effects more often than not take away valuable cpu and ram resources without actually adding anything. The visual effects are only good to show of stuff to your buddies just to say how cool the device is. After using it for a week you wont even know the presence or absence... while they still take up valuable cpu. That valuable cpu could be used for multi-tasking!
nilchak
07-08-2009, 11:59 AM
Ok, that's can be useful the first n times you look for that information. Then your brain has supposedly adapted and knows what kind of information is there, so the animation gets in the way.
At first the animation helps you, over time it slows you down.
It's like memorizing often used functions: selecting the option from a menu is a big help when you're starting to use an application, over time it's just quicker to use the keyboard shortcut.
I thinking you are still in the "desktop state of mind" when you say that.
Are you serious that I would rather take out the sliding Keyboard on my N180 and press a keyboard shortcut rather than have an easy to access on-screen menu or control to do some function ?
For the desktop many a times simplicity and speed matters so you can do repetitive functions quicker and your points hold true.
If you try to translate the same desktop UI objectives and principles to a mobile hand-held form factor - things change very rapidly and it doesn't fit.
UI is meant to be very tightly factored in with the device form-factor you are using. Trying to state desktop UI principles for a mobile platform is just plain silly.
Could you please move this discussion about animated vs static UI to another thread? It's actually off topic here.
GeneralAntilles
07-08-2009, 12:07 PM
And those effects more often than not take away valuable cpu and ram resources without actually adding anything. The visual effects are only good to show of stuff to your buddies just to say how cool the device is. After using it for a week you wont even know the presence or absence... while they still take up valuable cpu. That valuable cpu could be used for multi-tasking!
That's why the OMAP3 has that big PowerVR. . . .
The Clutter-based interface in Fremantle on OMAP3 will run way faster than Diablo could ever dream of on OMAP2.
sachin007
07-08-2009, 12:33 PM
Could you please move this discussion about animated vs static UI to another thread? It's actually off topic here.
I understand that it is off topic. But we just cant make a new topic for every couple of slightly off topic posts. Nothing wrong in you reminding...
daperl
07-08-2009, 01:41 PM
Could you please move this discussion about animated vs static UI to another thread? It's actually off topic here.
It is done (http://talk.maemo.org/showthread.php?p=303086).
I would be interested to know how much Qt stuff Symbian and Maemo will share. Symbian is expected to get a Nokia contributed UI overhaul in version ^4. That would include the vague "Direct UI" (better come up with a marketing name before it becomes DUI) and the "Orbit" Qt widget set designed for mobile UI:s, Qt Mobility APIs etc. The whole software suite will be rewritten to take advantage of those(see a pattern here?). I expect the new UI to be at least on the designers' table already.
I guess it would be safe to assume a lot of that will find it's way to Maemo too. Can any of you Nokia folks comment on this? It would be interesting to know if / how much the Harmattan UI or app suite will differ from its Symbian counterparts? Will we get a glimpse of it before it is released? Will there be any community input regarding the new UI?
Don't know if the "leaked Harmattan screenshot" was just a mockup, but I expect the coming UI to be very different from what it's now. I'm very excited about this even if it's still far away.
ragnar
07-08-2009, 04:43 PM
I guess it would be safe to assume a lot of that will find it's way to Maemo too. Can any of you Nokia folks comment on this? It would be interesting to know if / how much the Harmattan UI or app suite will differ from its Symbian counterparts? Will we get a glimpse of it before it is released? Will there be any community input regarding the new UI?
I was left thinking. (And maybe this should be moved then to yet another thread.)
Could you - or anybody - can come up with a good (as in realistic and pragmatic instead of idealistic) proposal on how to 'do' community input regarding the new UI?
... What exactly would you input on?
... How would the UI turn out differently?
I'm not trying to be sarcastic here, at all. But it's... the more I think about it the harder it is for me to come up with decent answers.
I'm now discounting the alternative of "just show the whole plans"... And even without discounting that: if we would show the whole plans, and then get n comments on it, ... Would following the democratic majority of the developer community lead to an optimal solution in terms of an UI solution? Wouldn't that be the worst kind of "design by committee" that one could imagine? Do a poll for "Feature X, do solution A or solution B" and vote which solution gets more votes? No?
It's an interesting topic, anyway.
Jaffa
07-08-2009, 05:21 PM
Could you - or anybody - can come up with a good (as in realistic and pragmatic instead of idealistic) proposal on how to 'do' community input regarding the new UI? [...] Would following the democratic majority of the developer community lead to an optimal solution in terms of an UI solution?
I don't know about the UI; but surely an exact same argument can be given for an API (developers use APIs, users use UIs).
And we've already seen what happens with Hildon when well intentioned developers go away for 18 months and then come back with a beta which has a practically fixed API, which lots of developers immediately start finding inconsistencies, edge cases, over-zealous specialisms vs. over generalisations.
Wouldn't that be the worst kind of "design by committee" that one could imagine?
Isn't this just traditional anti-open source FUD, but applied to the UI? Just because someone does something to the code base of an open source project, makes a suggestion on a document, comments on a proposed API/UI - doesn't mean the project leadership has to take it. However, it'd be arrogant in the extreme for anyone to claim that it's impossible that any form of external input from different viewpoints couldn't give some insight or comment which would improve the overall deliverable.
It's an interesting topic, anyway.
Indeed. The only valid answer I can see is the one we've heard before: "exposing this information for external comment from the community will reveal too much of our future plans".
This is a fine answer. But, of course, there's then no hint of roadmaps, design principles (not in the UX sense) or architecture plans on which the community can contribute. So, no contributions means the cycle continues and products which could've had free consultancy services from an empassioned expert community are shipped in a sub-optimal state[1]
Cheers,
Andrew
[1] They may be good devices. They may be excellent. But, by definition, if there's even one good idea out there which wasn't solicited, they're sub-optimal.
ragnar
07-08-2009, 05:35 PM
Isn't this just traditional anti-open source FUD, but applied to the UI? Just because someone does something to the code base of an open source project, makes a suggestion on a document, comments on a proposed API/UI - doesn't mean the project leadership has to take it. However, it'd be arrogant in the extreme for anyone to claim that it's impossible that any form of external input from different viewpoints couldn't give some insight or comment which would improve the overall deliverable.
Indeed. The only valid answer I can see is the one we've heard before: "exposing this information for external comment from the community will reveal too much of our future plans".
Yes, I think we mostly agree on the problematics of this issue.
I think the problem with API's etc. is real, but then again, in the long run this will be an iterative process. If something isn't in the first release, we can add it to the next release
It's just hard to me to think of good ways to get community input for the specific issue of UI.
Generally companies... Ok, let's focus even more: generally UI's are not revealed in advance because of competitive reasons. If we would have shown the Maemo 5 UI plans at the time they were ready for the first time, any smart competitor would have not commented anything on them, picked up on the good ideas, disregarded others and probably even come out with their own device before Nokia. Then end consumers - who don't know and care about the process of how things get done - would be just left confused. Showing our own cards is a very basic problem, and I hope everybody realizes that. We will be the first company out with the device with the Maemo 5 UI. If you wouldn't believe your UI is an competitive advantage and therefore don't care about that fact, then we can all go home already. :)
So, either you hold your cards really close to your chest, or you then do the complete opposite, and do like Mozilla, and open up everything all the time, right from the start. If Nokia = Maemo and nothing more, and if Nokia could crank devices out faster than any competitor, then perhaps there would be more options. But since Nokia > just Maemo, even Maemo does not work in a bubble. Revealing some parts of Maemo UI would reveal ... elements of "Nokia UI" - see that however you want.
-
Yes, members of the community could then give "free input", probably, but "free" here isn't truly free - it is with a rather large cost.
Jaffa
07-08-2009, 05:47 PM
I think the problem with API's etc. is real, but then again, in the long run this will be an iterative process. If something isn't in the first release, we can add it to the next release
Point taken; except once an API's in place it should be kept in place for backwards compatibility.
It's just hard to me to think of good ways to get community input for the specific issue of UI.
Iterating a UI is probably harder (I dunno, great UIs are beyond me: I'll just implement what someone gives me). Perhaps it'd be worth a retrospective on how community input (whether directly, from marketing or via seeing applications on the platform) has shaped the current UI vision.
If we would have shown the Maemo 5 UI plans at the time they were ready for the first time, any smart competitor would have not commented anything on them, picked up on the good ideas, disregarded others and probably even come out with their own device before Nokia.
Assuming said competitor could build hardware and software to a spec from a few screenshots/HIG docs/videos, to a high quality (still gotta get those good reviews) and through a reliable distribution mechanism.
I'd be fascinated to know which of Nokia's competitors you think could do that, cos I'll probably go and buy a device from them; even if they haven't got the mind-blowingly excellent Maemo 5 UI ;-)
Besides, a counterpoint (and Nokia do things Nokia's way, so this is fairly off-topic), the first two things that Palm showed off with the Pre were the device and the UI.
The hardware was a bit meh (OMAP3, touchscreen, slider, yawn). But the software impressed people.
We will be the first company out with the device with the Maemo 5 UI. If you wouldn't believe your UI is an competitive advantage and therefore don't care about that fact, then we can all go home already. :)
If you honestly believe that the Maemo 5 UI will give Nokia's Maemo devices a competitive edge in the world of Android, iPhone and webOS; I look forward to it! But perhaps the UI will be too constrained by previous technical decisions (at least one advantage of a complete move to Qt: the UI can be re-engineered entirely).
And, the big success from a UI point of view is how easily developers can produce consistent applications with its API. And here, Maemo 5's Hildon seems to be a long stream of cock ups (don't use stock icons or labels: they won't fit in a dialogue box).
Again, here, Qt can introduce some sanity as the approach there (to date, at least) has been to try and minimise accidental complexity. Redesigning a UI for a mobile device is essential complexity: arbitrarily introducing new API for project expediency is accidental complexity which could've been avoided.
Yes, members of the community could then give "free input", probably, but "free" here isn't truly free - it is with a rather large cost.
"Free" compared with other forms of external, expert, consultancy.
ragnar
07-08-2009, 06:00 PM
I'd be fascinated to know which of Nokia's competitors you think could do that, cos I'll probably go and buy a device from them; even if they haven't got the mind-blowingly excellent Maemo 5 UI ;-)
Well, I don't want to name names directly, but there are some well-known companies originating from Asia, for instance.
Besides, a counterpoint (and Nokia do things Nokia's way, so this is fairly off-topic), the first two things that Palm showed off with the Pre were the device and the UI. The hardware was a bit meh (OMAP3, touchscreen, slider, yawn). But the software impressed people.
And naturally that is the idea with Maemo 5 also. Showing the device and the UI at the same time.
That is why the Beta SDK doesn't show the full UI.
"Free" compared with other forms of external, expert, consultancy.
Well, yes, external consultancy costs money. But it can also offer consistency, with testing methodology, target user gathering, non-biased testers, consistent reporting metrics etc. etc. So they're not really comparative. You wouldn't replace one with the other.
ragnar & Jaffa:
I'm definitely going to try to distill some of this for my dialog with Ari Jaaksi at the Summit (http://talk.maemo.org/showthread.php?t=30120); the tension that ragnar is discussing (competitive advantage vs. openness) is one of the core issues of corporate / community interaction.
EDIT: I did some distillation in a post in that thread (http://talk.maemo.org/showthread.php?p=303235#post303235). If you want to continue your discussion over there (or just correct my misreadings of your arguments), you're welcome to!
Could you - or anybody - can come up with a good (as in realistic and pragmatic instead of idealistic) proposal on how to 'do' community input regarding the new UI?
...
I'm not trying to be sarcastic here, at all. But it's... the more I think about it the harder it is for me to come up with decent answers.
I was mostly asking out of curiosity, would be nice to know what's going on behind the scenes. I want to see a magnificient UI, and not be "meh" on the big day. I guess I'll just have to trust you guys.
To your question, I have absolutely no idea how to do it. :/ Especially considering that Maemo is going mainstream, and this community doesn't represent mainstream by any stretch of imagination.
VDVsx
07-08-2009, 08:41 PM
Well, I don't want to name names directly, but there are some well-known companies originating from Asia, for instance.
One of those almost rip-off everything that Nokia put in the market, even the name was partially ripped-off :D
nilchak
07-08-2009, 10:24 PM
Not only the one staring witl N and a ripoff of Nokia name, but also the one with H which is a big player now. They are quite capable of putting together a nice finger-friendly interfaces over older even more clunkier OS's like WM and I sense, even over Android. ;)
Jaffa
07-09-2009, 03:54 AM
One of those almost rip-off everything that Nokia put in the market, even the name was partially ripped-off :D
That's one of the reasons I was fishing. Do Nokia consider these Asian companies real competitors when their products are limited to China/... which are awash with copies? Or are Nokia's "competitors" those typical names we'd expect: Apple, Palm, Google, Microsoft, Archos etc.
VDVsx
07-09-2009, 06:20 AM
That's one of the reasons I was fishing. Do Nokia consider these Asian companies real competitors when their products are limited to China/... which are awash with copies? Or are Nokia's "competitors" those typical names we'd expect: Apple, Palm, Google, Microsoft, Archos etc.
China and surrounding country's constitute a very big market, but IMO the big competitors are other players, like some of the referred above, these, like Nokia, sell their products in a global scale. And don't forget that some big company also produce rip-off's ;)
deadmalc
07-09-2009, 06:36 AM
China and surrounding country's constitute a very big market, but IMO the big competitors are other players, like some of referred above, these, like Nokia, sell their products in a global scale. And don't forget that some big company also produce rip-off's ;)
China is the **biggest** market, don't forget most people in the world speak Mandarin (or dialect of) aka Chinese
I would be interested to know how much Qt stuff
Symbian and Maemo will share.
The interest is to align on the API level. Then each platform will
push its own identity and strengths based on the target users and form
factors of the products released. This means that UI and pre-installed
application might differ, and in some cases even significantly.
Will we get a glimpse of it before it is released?
Yes. The Fremantle API and Application Framework UI have been exposed
much before than in any previous release and we expect only to improve
the "release soon & often" principle in Harmattan. The announcement this
week even before a Fremantle final release is just a sign of this
direction.
Will there be any community input regarding the new UI?
Sure, we expect to improve and evolve based on the feedback received through various channels, the Maemo community being one of them. I agree with Jaffa that there is a lot of expertise out there and we could benefite more and better from it. However, I hope you also agree that it's sometimes too easy to find that "expertise" lobbying and it takes time and energy only to follow up and separate noise from signal. But this is what development teams do all the time, so nothing new here.
Another side effect we have seen is that showing UI concepts soon also confuse many users and even developers expecting what is actually a complete launch. So it's not that easy to fulfill everybody's expectations.
attila77
07-09-2009, 05:52 PM
OpenGL module should be there in extras-devel if not, please
report error to bugzilla.
Just to let interested people know, good Nokia folks just resolved this -> from today QtOpenGL really is the in Fremantle extras-devel repo.
Stskeeps
07-11-2009, 02:34 PM
Weird question, which I'm curious about because of Mer:
Will a/the future window manager / Qt-based Maemo desktop still be using libmatchbox2 for window management?
The reason why we ask is because Clutter is noted as no longer a major part of Harmattan and libmatchbox2 is using this extensively for one of the rendering modes. Should we spend time looking further into libmatchbox2 or is this a dead end regarding Maemo desktops?
Video of my keynote on Maemo Harmattan and Qt at Gran Canaria Desktop Summit http://bit.ly/10meEp
For what I know/remember, Matchbox is currently maintained only by the Maemo team since not even the OpenedHand (now Intel) developers that started it are putting hours on it. It won't be in Harmattan and I wonder whether anybody else will keep its development.
PS: About to finish my holidays. Back to the office next Monday.
For what I know/remember, Matchbox is currently maintained only by the Maemo team [...] It won't be in Harmattan
That's interesting, any idea what's going to replace it? According to slide 6 Harmattan will keep Xorg so presumably it'll need a window manager.
Stskeeps
07-24-2009, 02:17 PM
That's interesting, any idea what's going to replace it? According to slide 6 Harmattan will keep Xorg so presumably it'll need a window manager.
Look at Qtablet and such to see that a Maemo-like WM is fairly easy to accomplish.
Kypeli
07-24-2009, 02:21 PM
Look at Qtablet and such to see that a Maemo-like WM is fairly easy to accomplish.
QTablet uses qlwm.
Look at Qtablet and such to see that a Maemo-like WM is fairly easy to accomplish.
That uses a work-in-progress (http://qtablet.laginen.net/doku.php?id=qtablet_architecture#qlwm) fork of qlwm (http://qlwm.get.to/) apparently.
cristids
09-12-2009, 06:18 PM
Maybe a little late to this thread, but I think it is important to clarify some issues:
1. Is it true that application compiled with qt, when the sdk (non beta) is released, for maemo 5, will not have the same look as the gtk+ ones?
2. Since there is no support from nokia for gtk in maemo 6 there is no way to know if gtk applications compiled for maemo 6 will look as they should, like their qt 4.6+ apps
3. At this point as a n900 user I am supposed to buy a device that should get community and commercial support, but at this moment the community/companies do not know if fremantle is worth developing for.
4. As a developer I am supose to come and develop for this device knowing that I may have to totaly rewrite my code. Words like we don't know what it will be implies this.
Thanks for your patience.
attila77
09-12-2009, 07:25 PM
There has been some talk about this on the maemo-developers list, you might want to check that out. Search for posts by Kate Alhola. Long story short
1. Qt stuff looks roughly the same, except for a few specific widgets (like calendar picker)
2. There is no way to know how ANYTHING will look in maemo 6. Even if you are GTK, that doesn't mean a maemo 4 app will act Fremantleish just after a recompile
3. Yes (was that a question ?)
4. You will certainly not have to totally rewrite your code, regardless of your choice of GTK or Qt.
Here is Kate's closing line on the discussion:
Always, freedom of choice leaves some space of confusion between choices.
Let's simplify:
If you have already GTK+/Hildon application, fastest and easiest way is
to get it for N900 is continue using Hildon. It is clear that N900 will
be most successful maemo device so you will have a lot of users
for your software. There is no reason rewrite existing GTK+ program
with Qt for N900 .
If you are writting a new application and you like to make your upgrade
path to Harmatan as easy as possible or if you would like make
your application cross platform also to other Nokia platforms,
then yuo should consider Qt as number one option.
I also understand that there is many GTK or Qt lovers ones that would write
their application with GTK+ or with Qt any case because it is their
personal
choice and that is their right.
vBulletin® v3.8.2, Copyright ©2000-2012, Jelsoft Enterprises Ltd.