Active Topics

 


Reply
Thread Tools
NvyUs's Avatar
Posts: 1,885 | Thanked: 2,008 times | Joined on Aug 2009 @ OVI MAPS
#11
Originally Posted by svdwal View Post
Qt for Nokia is an asset as long as code written for Qt can be deployed on lots of platforms. That is after all why Nokia bought it in the first place. So, with Qt in place, Nokia has a very good value proposition to (commercial) developers, which is the size of the Qt user base. Qt is capable of hiding the differences between Symbian^4 and Maemo 6 for a lot of apps, and that means that Maemo 6 and Symbian ^4 devices can be counted together as a single platform.

But, as soon as there are differences between Maemo 6 and Symbian^4, there won't be a single platform anymore, and the value proposition Nokia is making to (commercial) developers drops hugely in value.

Nokia should know this because they had at some point three different UI's. S60, S80 and S90. And even though S90 and S80 were almost identical, the differences were big enough so that only the most trivial apps did not need porting. S60 and S80 were so different that all UI parts of apps had to be rewritten. A bit later, Nokia killed S80 with the excuse that two UI's were too expensive to maintain.

And here we are, 5 years down the road, and Nokia is making exactly the same mistake again. I believe that "flabbergasted" is a better description of my emotional state than 'anxious"
why do they have to maintain two in future? s60 no longer as to be maintained by nokia as its dead and all code is/will be contributed to symbian foundation for the new unified symbian platform, where it will not be there sole responsibility to maintain.
btw you forgot about s40 from what I've read in the future sometime symbian will replace it on low to mid priced devices so they will have gained 1 platform and lost 1 1/2
 
Posts: 3,841 | Thanked: 1,079 times | Joined on Nov 2006
#12
I am not familiar with Qt, but it looks to me like svdwal has a good point. From what I can figure out Qt appears to go down the road of the Hildon add-on to Gtk+, where in many places the original Gtk call was simply replaced with an equivalent Hildon call. The right thing would have been to leave as much as possible in place, and just provide library versions where the standard Gtk calls were modified to do the Hildon thing.

Instead, to create a multi-system (desktop+Hildon) application you had to sprinkle the code with #ifdef and the like. Obviously the application itself will always have to be small-display compatible, but in addition to that the Hildon version of Gtk+ added (in my opinion) unnecessary replacement functions for standard stuff.

So, instead of the special-for-Maemo-6 Qt functions, wouldn't it be possible to massage the underlying objects/functions, to minimise the boiler plate code changes?
__________________
N800/OS2007|N900/Maemo5
-- Metalayer-crawler delenda est.
-- Current state: Fed up with everything MeeGo.
 

The Following 4 Users Say Thank You to TA-t3 For This Useful Post:
Posts: 3,319 | Thanked: 5,610 times | Joined on Aug 2008 @ Finland
#13
Why ? It's a framework based framework build on top of a framework which is a part of that first mentioned framework. What's not clear and understandable here ?
 

The Following 2 Users Say Thank You to attila77 For This Useful Post:
Posts: 182 | Thanked: 540 times | Joined on Aug 2009 @ Finland
#14
If you look at Maemo 6 UI framework technical preview, you can notice that widgets in this framework are built on top of Qt's QGraphicsView technology. If you look at Qt Labs blogs, QGraphicsView has biggest amount of blog articles published among all categories (http://labs.trolltech.com/blogs/cate...graphics_view/). Note that QGraphicsView is rather old -- it first came as Qt API in 2006, way before Nokia has considered anything regarding Qt.

QGraphicsView is used as basis for KDE4 Plasma. This is currently major user of QGraphicsView API among released software. And common trend in Qt circles is to move interfaces to something QGraphicsView based.

So if you look through this perspective, Maemo 6 UI based on QGraphicsView is not really something radically departing from what "mainstream" Qt development is geared towards. Of course, it has its own quirks and design decisions but that is something you would need to look at with real facts and circumstances considered.

Interestingly enough, there is no widget set in Qt API based on QGraphicsView itself. So If you are going to use QGraphicsView, you are building widget set yourself.

I know almost nothing about Symbian^4 design decisions but to me it looks like they are going a similar direction with QGraphicsView being a basis for their widgets.

Now, this is interesting: what are differences in operating systems *behind* UI that can influence UI to be substantially different? You may hide certain portable things behind a common facade, however, is there anything that is really so different in Symbian/Unix designs that is hard to unify/represent in the same way?

Last edited by abbra; 2009-11-18 at 17:45.
 

The Following 2 Users Say Thank You to abbra For This Useful Post:
gecebekcisi's Avatar
Posts: 103 | Thanked: 45 times | Joined on Oct 2009 @ Istanbul, Turkey
#15
I am total newbie but I guess Direct UI could be used for touch based desktop systems in the near future too, so the source compatibility break would be caused by developers' target UI (touch&nontouch) decision, instead of target platform decision.
__________________
Useful links for newcomers: / Aramızda yeni olanlar için, bazı faydalı bağlantılar (içerikler İngilizce'dir):
|[ New members say hello / Diğerlerine merhaba deyin ][ New users start here / Buradan başlayın ]|
|[ Community subforum / Topluluk Alt Forumu ][ Beginners' wiki page / Yeni başlayanlar için Wiki sayfası ]|
|[ Maemo 5 101 / Maemo 5'e Giriş ][ Frequently Asked Questions (FAQ) / Sık Sorulan Sorular (SSS) ]|
If I can help with anything else, just ask / Yardımcı olabileceğim birşey varsa, sormaktan çekinmeyin

Last edited by gecebekcisi; 2009-11-19 at 04:20.
 

The Following User Says Thank You to gecebekcisi For This Useful Post:
Posts: 22 | Thanked: 22 times | Joined on Sep 2009
#16
I think this is indeed a very bad news. I was under impression nothing could break the Qt cross platform as up until now you were able to create an application and run it in Linux and Windows and it always looked proper on the host os. Hack I even took a windows small app and run it on wm 6.1 and it looked as it should. Just like a native application.
I really cannot understand why when qt gets compiled to maemo the UI doesn't bind to an underline maemo library of widgets, same goes for symbian or linux or something else and look the same from a coding perspective the same. And use in addition styles to skin as desired.
If multi touching doesn't work on that platform then simply it will be disabled. If touch screen is not available than disable that too.
 
daperl's Avatar
Posts: 2,427 | Thanked: 2,986 times | Joined on Dec 2007
#17
Wow, if the OP is correct, what an epic fail. Again, if true, the person who made this command decision should be sent to the mail room.

I'll try to make this simple: Branching is the "goto" of software design. If you don't know how to extend functionality at this high of a level without breaking things, get out of the way. You're most likely not qualified to design software. You might be an excellent coder, hacker, ..., whatever, but you're lacking some high level abstraction skills. Or maybe just ask someone for help, but seeing what I see above is heresy. I think I'm gonna be sick.
__________________
N9: Go white or go home
 

The Following 6 Users Say Thank You to daperl For This Useful Post:
Posts: 182 | Thanked: 540 times | Joined on Aug 2009 @ Finland
#18
I would recommend reading Plasma documentation on why traditional widgets are not enough for "contemporary" UI development. http://techbase.kde.org/Projects/Pla...aysOfThePlasma is a good start. Don't know what was behind Maemo 6 UI but to me Plasma's arguments look quite close.

I have seen many commercial applications for Windows done with and without Qt. Trend there is certainly going outside of capabilities of traditional widgets provided by "standard" UI toolkits.
 
Posts: 488 | Thanked: 107 times | Joined on Sep 2009 @ Asgard / Midgard / London
#19
Originally Posted by attila77 View Post
Why ? It's a framework based framework build on top of a framework which is a part of that first mentioned framework. What's not clear and understandable here ?
Are you Humphrey Appleby?
 
Posts: 20 | Thanked: 71 times | Joined on Sep 2009
#20
Originally Posted by abbra View Post
I would recommend reading Plasma documentation on why traditional widgets are not enough for "contemporary" UI development. http://techbase.kde.org/Projects/Pla...aysOfThePlasma is a good start. Don't know what was behind Maemo 6 UI but to me Plasma's arguments look quite close.

I have seen many commercial applications for Windows done with and without Qt. Trend there is certainly going outside of capabilities of traditional widgets provided by "standard" UI toolkits.
What I would be interested to know is that if QGraphicsView is the way to go, which means not using standard (let's call them e.g. "Desktop") Qt widgets...

Then what exactly is the strongly emphasized cross-platform story of Qt on the UI level (not just Nokia's Maemo and Symbian, but other Qt platforms)?

To maximize cross-platformity, one extreme possibility would be for each and every application to code their own QGraphicsView-based widgets themselves from scratch, but I fail to see the cost-efficiency and UI consistency in such approach.
 

The Following User Says Thank You to msoini For This Useful Post:
Reply

Tags
cross-platform, dui, future, harmattan, libdui, maemo, maemo 6, plain qt, programming, source compatibility, symbian


 
Forum Jump


All times are GMT. The time now is 13:56.