Re: Say NO! to Qt-based Maemo!
 

I develop with Qt for years. It's a really GREAT framework and not only a GUI toolkit (dbus, xml, network, graphics, sql, and much more), all that with a well organized object hierarchy, great documentation and support available.
Trolltech guys have great experience over crossbuilds and embedded system.
You really write code once, build and run it everywhere.

Before hating, please experiment it a bit, it's has very nice surprises.

Just one example: qt works with properties, signal and slot, just adding a couple of line of code you may export those on DBUS, for that reason I'm coding daemons too with qt, linking qtcore and qtdbus, doing nice things with very little coding.

Anyway you are always free to use glib, gtk, dbus, expat, libc, stdc++, vala, and mix all the other libraries, finding documentation in several place without a great offline crossreferenced help, playing with autotools and so on if you feel better :)

In the long term I think that Nokia wants to provide for its devices an integrated IDE like XCode for apple.
The difference is that here the code is free, and you have bindings for a lot of language and not that objective-c crap.
You are always able to mix qt with other libraries c/c++ code.

So IMHO it's a nice line I'm very happy for that.

Niko

Re: Say NO! to Qt-based Maemo!
 

Why should i learn yet another language? I think anybody with basic C knowledge is able to code something in C++/Qt. Vala is a new language, C++/Qt is not a language, but an addition to C++

Re: Say NO! to Qt-based Maemo!
 

Taking into account how few of the members of the Maemo community actually are developers of any shape and kind, questions about changes in the basic workings of the system will always end up a tad frantic. To me, this thread has more of that in it (without forgetting that OP and you actually are developers) than actual technical concerns in regards to how it will affect the device.

Regarding MOC, I do wonder what the equivalent tool when developing GTK+ applications is. I develop GTK+ applications without describing the GUI of my application in some metalanguage so equating "using MOC to develop Qt applications" to "using GTK+ (the library and headers) to develop and run GTK+ applications" comes across as a tad off target. Qt brings MOC to the table together with libraries and headers.

This leads to two of my actual concerns: code size and performance. The N900 is limited as it is (without serious tinkering) and to more or less direct much of the future development along a line with bigger binaries that depend on a larger application stack might not be the best.

Of course this has to be weighed against the potential ease in developing or porting new applications but to just brush it over with "C sucks, C++ rocks" as I've seen in other threads here is to, in my opinion, overlook some of the real consequences.

Regarding armchair shed painting, I agree. Getting involved is the best thing but it's not an option but for a select few. As you yourself state later on in the thread, the quality you need to be able to produce is proportional to how important the component is.

Re: Say NO! to Qt-based Maemo!
 

The strength of Maemo/MeeGo is that you can use more than one language and toolkit, which is great for developer choice.

Qt and GTK+ are "toolkits". If you are a bad craftsman, it does not matter how good your tools are. If you are a good craftsman, you can create good results even with suboptimal tools.

It's not about Qt vs GTK+, it's about good and bad UI design.

Of course, if you want perfect platform integration (and the right widgets), you have to go with Hildon for Maemo 5 (plain GTK+ is not enough to make your UI fit in well) and if you want perfect integation into Harmattan, you have to use DUI (again, plain Qt will probably not be enough).

Say NO! to negative threads like this one. Invest your time in making apps better. You don't have to be a developer for that.

Re: Say NO! to Qt-based Maemo!
 

Weak argument. Between learning a new language and learning a new toolkit, the former should always be easier (unless it's a big language - some call it a foundation of languages - like C++). Also, the quality of your c-based C++ code would probably not be very high.

Re: Say NO! to Qt-based Maemo!
 

Yeah, I had positive experiences too, nice guys (and it's not that bad even when we disagree about something). I can understand some people preferring certain technologies, but occasionally it gets from a 'why I like XYZ' to a 'my tool is better than your tool' dispute which rarely brings good results. For the record, I like Qt better even though I used both in the past, think gobjects are a bigger hack than moc, so there, let the flame begin :) But it's not really a fight. Maemo/MeeGo is in the unique position in the embedded arena that you can have both (and more) toolkits, code for whatever you like. Dissing Nokia for not pushing your favourite tool is IMHO pointless. Qt people could have said just the same during Maemo's GTK+ phase.

Re: Say NO! to Qt-based Maemo!
 

Are you nuts?

If you've never used Qt, try it. It is truly outstanding.

My only complaint with Qt is performance, but this will become less of an issue as devices continue to mature.

Edit: Sorry; directed at OP to avoid any confusion. :)

Seriously, spend a few months working with Qt and you'll get it.

Re: Say NO! to Qt-based Maemo!
 

I agree about quality of c-based code, but it's a way to start coding and to "meet" C++.

You totally missed in the other matter. If i learn vala, i should also learn bindings for GTK, Gobject .dbus.vapi, kernel26.vapi ... .. .. .and so on.

Qt lets you use kernel headers and other libs as you like and already know.

The question is thae same. Why should i learn another language and do _everything_ in a different way rather than learn some new things and do others as i already know?

Re: Say NO! to Qt-based Maemo!
 

DEB is couple of ways technically inferior than RPM.
Let's just name the couple: RPM supports embedded GPG-signatures natively and transactions, DEB does not. Politically RPM is chosen by LSB, and compatibility between Linux-systems is never high enough.
http://wiki.openvz.org/Package_managers#Commands

What it comes to programming languages, for dynamic programs use Python or Java because GC and optimization possibilities. For device drivers and microkernel C and when needed C-embedded assembly. For other non dynamic memory applications what ever you like, but because there is Python interpreter already probably running on the machine in shared memory, why don't use Python (or same for goes for Java but not in Maemo/Meego unfortunately).

Before when QT was only GPL, GTK was the better choice. Now when QT is LGPL, I see differently and maybe like QT's OOP from the ground up better than GKTmm which is like a small kludge to make C interface to OO-one.

IMHO, Ugh

Re: Say NO! to Qt-based Maemo!
 

Okay, here is my 2 cents about the matter.

I don't like Qt. However, I like GTK and stuff even less, because there is no viable development environment for them.
Qt Creator just barely passes my requirements, and there is no IDE that supports Hildon/GTK development on Windows, sorry, so it is out of the question for me.

It makes no sense that you don't like Qt because it uses C++. You know, they actually TEACH C++ at school. If you didn't get it, it is your loss.
I would anytime prefer a C++-based environment. (However, my favourite language of choice would be C#.)

By the way, GTK+ WILL remain an official toolkit for Meego because Moblin already uses it, so no complaints there.

Re: Say NO! to Qt-based Maemo!
 

Our options are C, C++, Perl, Python, GTK, QT, etc..

We speak more languages than the EU and have more bindings than a gimp & bondage factory.

So no more "my language is better than your language" or "my library is better than yours" or "my penis is bigger than yours!".

If you have the motivation then anyone can join in and create stuff.

Its all good - what more do you want?


We can have our cake and eat it..
..and I like cake!

Re: Say NO! to Qt-based Maemo!
 

Exactly.
I spent a lot of time learning Gtk+, Gobject, GNOME & Freedesktop technologies, now Hildon stack on top of it. Got to love it.

Now you're telling me:
Forget it all! Here's Qt - which is so much better. You need to learn everything again.

Re: Say NO! to Qt-based Maemo!
 

Did you follow the link given by OP? The one about C++ and its properties and the problems that come with it? I'd gladly agree it's a tad biased but it stays technical without getting ranty and it's not a pretty picture that is painted.

There are problems connected to using C++ as the main language for something as central as the preferred toolkit. As simple things as using a debugger can turn incredibly ugly even with moderately sized projects on account of C++, by design, being hard to interpret in object form. That in turn results in harder to debug programs which leads to lower quality code and that's a pain no matter how you look at it.

C++ being taught in schools is not an argument for it being the best choice on a device like the N900.

With that said, Qt might very well be the best choice when it comes to application development but it is, in my opinion, a pity it's implemented in C++.

Re: Say NO! to Qt-based Maemo!
 

This is pure theory.

The whole OS is being converted to be Qt based.
Have you ever tried programming for KDE using GNOME technologies? It not only does look out of place, but you are lacking interfaces to the core desktop layer. Unless you code glue in Qt.

Ever tried writing bindings to Qt library? Not a nice job.
While GObject bindings can be autogenerated using gobject-introspection.

Re: Say NO! to Qt-based Maemo!
 

You're right. We should have never moved beyond batch commands on DOS, CP/M, etc. Heck, writing VAX VMS shell scripts in vi is the ultimate!

:p

Re: Say NO! to Qt-based Maemo!
 

I personally prefer to develop only in Qt. It simplifies a lot programming.

Re: Say NO! to Qt-based Maemo!
 

All the GTK apps i've seen released on here and in ovi look bland outdated and wreak of black and gray.

If Qt /C++ can make apps look better and offer an easier development platform, which judging from demos they will, I'm all for it.

I really don't know why anyone would want to code in C in the year 2010.

This isn't 1995....

Let progress like the rest of the software development world.

Re: Say NO! to Qt-based Maemo!
 

Yes I agree that having to re-learn stuff can be annoying, but coming to Qt without too much prejudice myself, I was actually amazed how easy and useful it was. Most of the arguments agains Qt seem to come down just to this - "can't/don't want to spend time learning anything new".

Re: Say NO! to Qt-based Maemo!
 

F*** it! I'm going back to punch cards.

Re: Say NO! to Qt-based Maemo!
 

Those highlighted sentences are utterly insane.

I was going to refute those arguments but I do not want to be drawn into a holy war.

What I like about maego, meego & n900 is the desktop/library is not the star - it is the applications.

Until now it was refreshing not to hear about the whole "gtk vs qt"/"gnome vs kde" arguments again.

People have enormous choice in how they want to write software for the n900. Many different aspects of knowledge is brought to the table because different people use different languages.

These technologies are tools.

But you had to open your big f***ing mouth and complain about it and the ugly-warty head of "gnome vs kde"/"gtk vs qt" rears it's ******ed drooling head again.

Thanks for that.

Re: Say NO! to Qt-based Maemo!
 

Bling isn't everything. Me being able to change the theme is not worth anything if the system isn't stable on account of poor quality applications. Sad but true.

And when it comes to C being outdated, I'm sure them 100+ lines of C code commited into the main Linux kernel source tree every day is just 1995 all over again. Not to mention all the applications that form the base of everything you do on your N900 and on almost all other Linux based systems.

Ease of use is progress, bling is not.

Re: Say NO! to Qt-based Maemo!
 

Well, I disagree with the part of "learning everything again". Some basic concepts in software engineering don't change all that much from language to language.

As for learning, that's part of being a software engineer: There are always new languages and new libraries to learn. If you don't continually learn, you might be left behind eventually.

Re: Say NO! to Qt-based Maemo!
 

I'm amazed that people here think the language defines how well a piece of software is written.

I thought things like principles of good design, problem solving, you know stuff like that is what makes you a good programmer.

I must be naive.

Re: Say NO! to Qt-based Maemo!
 

I see you're new to this whole "let's flame things we know nothing about" thing.

Re: Say NO! to Qt-based Maemo!
 

I'm fine as long as there's both GTK and Qt options. Among others. I prefer to write in C or Vala, but I see nothing wrong with hacking occasionally on C++ and Qt (got to learn it bit by bit), and I'm looking forward to nice Qt apps written by other folks (as well as any GTK apps they can churn out).

I for one don't agree with the 'written KDE looks bad in Gnome and vice versa' claim. I've always been using a mix of applications (on my desktop) written in everything under the sun (Motif, GTK, Qt, WxWorks, heck, even OpenLook, and more). Me happy still.

Re: Say NO! to Qt-based Maemo!
 

Qt will be fine and happy under Gnome. If you're using the right style plugin (QGtkStyle or QCleanlooksStyle), widgets are actually drawn using Gtk - you can't get much more native than that.

(Qt on Maemo works the same: widgets are drawn using Hildon/Gtk.)

As for other platorms inside KDE (for instance), it depends on the capabilities of that toolkit. If you've set up a Gtk theme, you might be able to get close - but it's not fully native like the QStyles.

Re: Say NO! to Qt-based Maemo!
 

The problem is that too many put "It's ugly!" (which is purely subjective) against "It doesn't crash very often." (which is way more objective and you can actually count the times it happens) and prefer things that are pretty over things that are easy to develop, debug and maintain. And that's not even taking into account the difference in what code actually is run on the device.

Picking the right tool for something is usually the first step towards solving the problem in a good way. A great programmer can perform miracles even with a not so good tool but great programmers are scarce. This makes it important to pick the tool that gives the most programmers the best chances of at least not failing miserably given some time to practice.

Qt has very good documentation. The toolkit is versatile and is very actively developed and refined. This is all good. But, the easiest way[1] to harness the power of Qt is to write the business code in C++ too. With this you leave the comfy Qt corner and have to make your own design decisions and solve your own problems in a language that I find sub par for just that. Following the link posted by OP is a good introduction to at least thinking about this.

So, I'd say it's not you being naïve, since this is not a question of what makes someone a good programmer, but it's about you and many others asking, in my opinion, the wrong questions.

---
[1] Yes, there are things like PyQt but I haven't tried this out and approach this from a pure C/C++ angle.

Re: Say NO! to Qt-based Maemo!
 

As I outline above, if you're calling Qt on any of today's platforms ugly, then you've the parent toolkit to blame. Qt isn't actually defining that style, it uses existing APIs to render the widgets.

I question this. Are you saying Qt itself has these crashes? Because in some years of using it now (often pre-release, I've been using 4.7 on my desktop for well over three months now) and I'm still yet to experience many crashes caused by *Qt*. I thought I found one the other day, and it ended out (after a few days of investigation) to be my fault, not Qt's.

While this is just as subjective a statement as someone saying 'Qt is buggy', I don't think that's a statement that you can claim to *objectively* make without measurement and statistics.

I don't see your logic here.

Your point implies that the easiest way to use the power of Qt, is to not use Qt, and go back to all the headaches of C++ that Qt helps relieve you of? (QObject signal/events, most of the details of memory management - unless you want to deal with it, etc).

This doesn't really make sense to me.

It's worth noting at this point that the link of the flaws of C++, while a good read, is actually addressed to some extents *by* Qt.

It's not even that, so much as people not asking questions, and using knee-jerk reactions based on misinformed opinions.

Really, the best way to get involved in this discussion is to find someone *knowledgable* on both sides of the debate, learn from them, ask them questions, and then you'll have a balanced opinion.

For the record, at least in my experience, PyQt/PySide are pretty useful. I've used them for prototyping a few times.

Re: Say NO! to Qt-based Maemo!
 

You must have missed:
Recommended read:
Five Little Languages and How They Grew

Small languages that are yet expressive make all of your mentioned principles easier to follow.

Re: Say NO! to Qt-based Maemo!
 

You must have never used a filechooser dialog on GNOME then, from a Qt app. Or try KDevelop on GNOME ... UI is look&*feel*, with *feel* relating to the app's behaviour, and whether its surprising to the user or not. The style plugins still have a long way to go, IMO.

Re: Say NO! to Qt-based Maemo!
 

It's way off topic

Re: Say NO! to Qt-based Maemo!
 

Well, since you mentioned it, I just went and did it.

One dialog is from GEdit, one is from the Qt Creator instance underneath.

To be honest, they look pretty similar to me. :)

(In other words, you're probably blaming KDE on Qt. Don't.)

[edit: also, if you'd done your research, you'd know that - used properly - Qt uses native file open dialogs per platform. See: http://doc.trolltech.com/4.6/qfiledialog.html#details]

Re: Say NO! to Qt-based Maemo!
 

Use them. I talked about feel. Not look. There are subtle surprises everywhere.

Re: Say NO! to Qt-based Maemo!
 

I am not a programmer, but I have friends that are and that tell me Qt is great. But, what amazes me is - whenever the developer/creator/designer (in this case Nokia) decides to implement serious changes to their product, there's always an "old-school guy".

Now, the "old-school guy" is a person who claims that all the new features are somehow bad and that the old solutions were far better. They know what is best for the product - better than the company that actually made the product. Then they give reasons which probably have some basis in reality, but always miss the point. The point being: the product should be good for the majority of people, not for the select few.

I'm not saying all change is good, but I'm saying that no change is definitely bad.

And, as I said, I'm no programmer and most of you guys are. I'm an illustrator and a designer and I got an N900 for its multimedia and web capabilities. I never ran Linux, I spend my time in Photoshop and 3ds max and I use Wacom instead of code to send my thoughts out there. And I'm loving the device and what it may bring. No one has the right to tell me that its hacker-only or whatnot - as I use it daily with much joy and success.

So, here's my non-programmer point of view:

Qt will bring more interested parties (other than Nokia) which will result in more apps, better support, more possibilities.

It will bring more developers (ability to write one code and deliver it to multiple platforms vs the ability to write multiple codes for multiple platforms) which will, again, result in more apps - both from large developers and from talented individuals and small independant studios as it will cut costs for those with limited budgets. Bigger markets for the same development costs.

It will also bring easier usage of multiple devices - if my netbook can run the same software as my MID, than I don't have to adapt to two different applications to do the same thing on two platforms.

It will bring more devices and more choice. Want a HW keyboard? Don't want a HW keyboard? Want a 7" screen or an ultra-portable device?

Ofcourse - fragmentation is the downside. But its PC vs Mac all over again. I would rather have some fragmentation and a choice than have Steve tell me what I want and how I want it. But we all agree on that :)


And some of you are willing to give all that up because - what - you don't like C++?

Re: Say NO! to Qt-based Maemo!
 

Apparently I didn't manage to make myself sufficiently clear. I'll try to inject my comments in your text below.

My point was that people use subjective measurements to decide technical issues. Some say that skinning an application is important (I don't), some say that "It's ugly!" looking at a GTK+ (or Qt application) and want to change toolkit over that (which I think is the wrong way to pick the best toolkit).

Personally, I want things to work. And work well. Bling is superfluous junk that drags the code base down making it harder to maintain. But that's just my opinion.


No, I'm saying that business code written outside of the Qt corner is the cause for the many bugs and hard to debug faults. C++ is hard to use well and easy to make mistakes in that are subtle and hellish to debug. Qt in itself hides lots of the magic making it pretty easy to use but an application isn't only the GUI, it's also the business code that actually perform the work when I click on the buttons.

Here I urge you to go back and re-read my message. I can't understand how badly I put things if you got this impression.

My point is all about the business logic, that is, everything that is not Qt but uses it to get a GUI.


I try to ask questions. And I try to read very carefully when answered. Sadly I still get the impression that very few think about things other than GUI looks and bling.

When it comes to GTK+/Qt and C/C++ I use my experience and the weakest link here is C++. I have no trouble with Qt, at all. It looks very polished and versatile, as I've stated earlier. The trouble here is directing development more towards C++ in business logic which in turn will result in more developers churning out code that is hard to develop and maintain.

That is all.

Re: Say NO! to Qt-based Maemo!
 

Referring to the thread title, as I often say to my kids, dont say no till you have tried it.
Having tried it, I am impressed with the richness of Qt, its availabilty on multiple platforms, and accessability to learners via PyQt to gurus who want to go all MVC stylee.
documentation is excellent, lots of examples and Maemo integration is excellent, and very good tool support with the likes of qt designer and eric for python and qt creator for Cpp.

Re: Say NO! to Qt-based Maemo!
 

That's supposed be a coding error, actually. "The easiest way to create a QFileDialog is to use the static functions. On Windows, Mac OS X, KDE and GNOME, these static functions will call the native file dialog when possible." Now, if the developer of the app CHOSE not to use the native dialog (so he could implement custom filtering, etc), that's not the fault of the toolkit.

Hey, I actually do that regularly, it's not that bad. QObjects/moc trickery does give you a fair amount of introspection, and all bindings have their 'magic tools' that do the binding generation for them (we've got a full hat of those :) SIP, Shiboken, boost, SMOKE, you name it)

Re: Say NO! to Qt-based Maemo!
 

I use them daily. Do you have any specific bug reports or example(s) for me to test? As I use a mixed environment, this is an issue I care about, so if there are problems I'd be interested to track them.

Re: Say NO! to Qt-based Maemo!
 

What has this got to do with 1.2? That seems to have the same UI and apps as 1.1

Re: Say NO! to Qt-based Maemo!
 

Absolutely nothing.