Reply
Thread Tools
w00t's Avatar
Posts: 1,055 | Thanked: 4,107 times | Joined on Oct 2009 @ Norway
#61
Originally Posted by puelocesar View Post
You can think whatever you want. In my opinion, and you can find several examples illustrating that, a software that doesn't attend the user needs is irrelevant, no matter how well engineered it is.
And where am I saying that they shouldn't attend to user needs, pray tell? *ALL* my post says is that *IF* DUI (or anything else) is needed, it shouldn't duplicate existing work (like QML+QtAnimation), and it should be properly designed. So far, from what I've seen, and from reading the notes of a few other people who have looked into DUI, it doesn't look all that fantastic, as well as looking remarkably foreign compared to the *rest* of Qt.

Originally Posted by puelocesar View Post
Of course I'm not saying things shouldn't be bad engineered, don't misuse my words, and again, I still doesn't see how an abstraction layer can be so harmful. KDE uses one the same way and there's no one pointing fingers at them.
DING DING DING! So we agree then?

Let me repeat myself:

Originally Posted by w00t
I'm not saying that means should be dictated by a lowest common denominator, and that there is absolutely no need for DUI simply because it doesn't exist - but as far as I can tell from what I've read up on it, there isn't any need for it because QtAnimation and QML and other similar technologies are already working towards the goals it seems to want to achieve, in a more agnostic, abstract fashion.
__________________
i'm a Qt expert and former Jolla sailor (forever sailing, in spirit).
if you like, read more about me.
if you find me entertaining, or useful, thank me. if you don't, then tell me why.

Last edited by w00t; 2009-12-01 at 16:00. Reason: clarifying a few terms
 

The Following User Says Thank You to w00t For This Useful Post:
Posts: 24 | Thanked: 38 times | Joined on Nov 2009
#62
Originally Posted by puelocesar View Post
Of course I'm not saying things shouldn't be bad engineered, don't misuse my words, and again, I still doesn't see how an abstraction layer can be so harmful. KDE uses one the same way and there's no one pointing fingers at them.
And you don't see the problem with that statement? The goal of Qt is easy cross-platform development. The reason for Qt on Symbian, Maemo and WinMo is to be able to easily develop across these (different, but similar) mobile platforms.

The difference between KApplication and QApplication is that QApplication runs on any Qt-supported platform, while KApplication requires KDE (libraries). If I wanted to restrict myself to developing just for Maemo (6), why would I need Qt anyway? Just because it is a nice library?

The cost savings that Qt offers for developing across these mobile platforms are purposefully thrown overboard here. I have yet to see an example of something that needs to be done on Maemo 6 that can't be done by QApplication etc. directly.

If I develop for iPhone, I'm developing one application. It runs on all iPhones and all iPod touchs. Same with Android. Obviously I need to take care of different screen sizes and so on, but that is doable. What I would like to know is how a sample Maemo 6 application source looks like in Nokia's view. How do I get to compile/run it on Maemo and Symbian. Obviously I want to be the best citizen I can be on each platform. So do I have to #ifdef my way around which classes I inherit from / use? What kind of a mess is that? Or am I expected to develop a library with the core functionality and then write 3 UIs on top of that, one for each mobile platform? I just don't get it.
 

The Following 4 Users Say Thank You to sjaensch For This Useful Post:
w00t's Avatar
Posts: 1,055 | Thanked: 4,107 times | Joined on Oct 2009 @ Norway
#63
Originally Posted by sjaensch View Post
So do I have to #ifdef my way around which classes I inherit from / use? What kind of a mess is that? Or am I expected to develop a library with the core functionality and then write 3 UIs on top of that, one for each mobile platform? I just don't get it.
This was exactly my point, but you expressed it much more succinctly here.

Thanks.
__________________
i'm a Qt expert and former Jolla sailor (forever sailing, in spirit).
if you like, read more about me.
if you find me entertaining, or useful, thank me. if you don't, then tell me why.
 
HangLoose's Avatar
Posts: 319 | Thanked: 289 times | Joined on Sep 2009 @ Lisboa, Portugal
#64
So, in a nutshell...

If I start developing with Qt 4.6, will the same program run in different devices just with minimal adjustments? Or is just a promise?

Same goes for platforms, if I write on Linux can it run on Win?
 

The Following User Says Thank You to HangLoose For This Useful Post:
Posts: 654 | Thanked: 664 times | Joined on Feb 2009 @ Germany
#65
Originally Posted by HangLoose View Post
So, in a nutshell...

If I start developing with Qt 4.6, will the same program run in different devices just with minimal adjustments? Or is just a promise?

Same goes for platforms, if I write on Linux can it run on Win?
The answer given to that earlier was: If you stick to plain Qt, then yes. If you use Maemo specific Qt extensions (DUI), then no.

The question is, what features will you miss if you stick to plain Qt and is it possible to use DUI only in small areas of your app (e.g. for 2 special buttons) without basing your whole UI on DUI?
 

The Following User Says Thank You to conny For This Useful Post:
Posts: 22 | Thanked: 22 times | Joined on Sep 2009
#66
Well the infection seems to be spreading. I think Qt lost it . In this article http://labs.trolltech.com/blogs/2009...ext-iteration/ they are saying new classes got in the QT special for maemo.

Several new Maemo 5 specific classes were added:

* QMaemo5ValueButton: Implements a “Picker Button”, basically a button with an extra value
* QMaemo5KineticScroller: Implements the Maemo 5 kinetic scrolling algorithm
* QMaemo5AbstractPickSelector: An abstract interface to implement Maemo 5 “pickers”, plus a picker implementation for time picking
* QMaemo5InformationBox: Support for Maemo 5 Banners and Notes
* QMaemo5EditBar: Support for Maemo 5 Edit toolbar

I think no cross developer can afford to use them so they are plain wrong. I mean in the end we wil have some symbian classes and some maemo classes and maybe some wm7 classes. What am I suppose to use? #ifdef don't sound so good.

And they are maemo 5 specific? What about maemo 6 ? Wil they have their own set? Nice.
 

The Following 5 Users Say Thank You to cristids For This Useful Post:
w00t's Avatar
Posts: 1,055 | Thanked: 4,107 times | Joined on Oct 2009 @ Norway
#67
Yeah. I came across this this morning, and immediately started dying inside. This is such a *terrible* idea, and I can't imagine who on earth signed off on it...

I imagine this is happening because it would take too long to work up the existing tech (QtAnimation & co) or to properly shoehorn Maemo concepts into the existing Qt API - and I can understand that - but stupid decisions like this can *only* harm uptake of Maemo development in the future. Save a few months now, ****** development uptake of your platform for a few years in the future.

QMaemo5KineticScroller scares me the most out of those I think. Who the **** came up with that monstrosity of an idea? I mean, I can almost understand some UI elements and widgets might require a more platform specific implementation, if at least temporarily, but kinetic scrolling is *not* something limited to one platform! Or does Symbian not exist at all now?
__________________
i'm a Qt expert and former Jolla sailor (forever sailing, in spirit).
if you like, read more about me.
if you find me entertaining, or useful, thank me. if you don't, then tell me why.
 

The Following 4 Users Say Thank You to w00t For This Useful Post:
Posts: 24 | Thanked: 38 times | Joined on Nov 2009
#68
Yes. I already have the first two #ifdefs in my application just to get kinetic scrolling. And here is the best part: as far as I can gather, that's not even platform-specific code (works for all of Maemo), but just a hack for Maemo 5! In Maemo 6, it will be done differently (i.e. there will be no QMaemo5KineticScroller)!

So either stick to vanilla Qt (which means your app compiles and runs also on Symbian, Windows and Mac) or be prepared to target *just* Maemo 5, then later *just* Maemo 6.
 
qole's Avatar
Moderator | Posts: 7,109 | Thanked: 8,820 times | Joined on Oct 2007 @ Vancouver, BC, Canada
#69
How about some naive optimism!

Maybe the Maemo 5 hacks are just that -- temporary "bridge" hacks to make the most of a bad situation, since Maemo 5 is out the door already and they can't fix that situation.

Maybe Maemo 6 will use standardized "mobile" widgets that will work in Symbian too!

Wouldn't that be a lovely world?
__________________
qole.org --- twitter --- Easy Debian wiki page
Please don't send me a private message, post to the appropriate thread.
Thank you all for your donations!
 

The Following 6 Users Say Thank You to qole For This Useful Post:
Posts: 356 | Thanked: 231 times | Joined on Oct 2007
#70
Judging from whole history of Qt I think qole is right - those are just temporary hacks to push round Qt4.6 block through square Hildon hole.
If they wanted to make it permanent names would be more like QMaemoKineticScroller etc.
Note also it is "Technical Preview" version of 4.6 for Maemo - not super-final-stable version. They may vanish as soon as official build of 4.6 will be released. Or more probably will be properly integrated into main sources with 4.6.1 release or something similar.
 

The Following User Says Thank You to vvaz 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 10:34.