They are, by and large, evil. That's why Stroustrup discourages the use of macros in particular and the preprocessor in general. That's why practically all newer languages got rid of the preprocessor (while copying many other concepts and syntactic stuff from C/C++).

I'm sure you can find plenty of literature on the subject if you are really interested. The points made by Mark Wilcox are valid. Just because people manage to cope with #ifdefs does not mean they are the best (or a good) solution for the problem. One of the greatest achievements of Qt was and is that it got rid of a hell of a lot of #ifdefs, increasing productivity (and testability) along the way.

Did you do actual programming with #ifdefs for multi-platform UI in single source? Don't you think it would have been much more fun and much more productive without #ifdefs?

So of course if you're developing software for Maemo version (because your customer wants that, or because you have Maemo device), you'll just do that and forget for example Symbian compatibility. And vice versa.

So you'll end up with a lot of software that could run on all platforms, but runs only on one, not because of required device features but because of simple source compatibility.

And isn't that precisely the concern this whole thread is about?

They are essentially a hack of C, meant for overcoming shortcomings of the language and the development framework.

If at framework design phase it's decided that application programmer should use #ifdefs for cross-platform development, that's simply bad design. Look at regular Qt for example. No #ifdefs needed for stuff that Qt does. That's an example of good design right there, look it up.

Biggest fundamental problem: When used in certain way, they are same as copy-paste coding. First you generate first version, then put it inside #ifdef, copy it inside #else and modify it in places.

If you don't know or believe what's wrong with that kind of coding, I can give a lecture on the subject... But that really is "programming 101" stuff, which I hope everybody reading this forum knows.

Now #ifdefs have their place of course but GUI design isn't one of them.
I'm not quite sure what solution you have given to this problem:

Somebody has developed an application for Symbian+Qt, let's say a simple drawing program to entertain small kids. It does nothing Symbian-specific. Now I want to compile for Maemo+Qt or even Tablet PC+Qt. What was your suggested solution?

My impression is that it does not just compile and sort-of-work.

How much do I need to change to make it compile and sort-of-work, before staring to actually tweak it to work well? Every widget name? Even signals and slots?

Ie. how much work do I need to do before I can even start to adapt it to a new platform?

Would it help if maemo would be based on gtk and clutter and you wouldn't have even possibility to run qt apps on it?

Guys. With enough #ifdefs you can make your app run both on Qt and GTK. But that's not the point. Take a look at what the trolls say about Qt portability on it's own page:

• Target multiple operating systems with one source code base

• Deploy code from one device target to another by reusing code

• Reassign development resources regardless of platform

• Future-proof code against platform changes

• Allow developers to focus on building core value of software instead of maintaining API

and, a little further down...

Qt is a comprehensive application and UI framework for developing Maemo applications that can also be deployed across major device and desktop operating systems without rewriting the source code.

* Design innovative user experience
* Develop compact, high-performance applications
* Deploy your Qt for Maemo applications to Symbian, Windows Mobile, Windows CE and embedded Linux devices

This sounds very good (and how it should be!) and IMHO is one of the main reasons Qt is as successful today as it is, but the Orbit-Dui-Qt-proper story in the thread above casts quite a shadow on the promises above, at least regarding the Maemo-Symbian-WinMo-Embedded segment

EDIT: bold the crux of the matter

But isn't that precisely the concern of this thread: birth of an environment, where you can't (compile and) run certain Qt apps on Maemo or Symbian or PC, not because they aren't suitable for the device interface, but because they have been coded using a non-cross-platform version of Qt?

I don't think Nokia is in a position to do that any more. They can try, but I don't think it'll work, there's too much competition (Android especially). It'll just hurt both device sales and software base of both Symbian and Maemo. Bad move business-wise. Consumers care about "millions of downloadable apps" kind of stuff, it's a big selling point, and this kind of move seriously hurts making that happen, both for Maemo and for Symbian. It'll turn directly into lost market share.

I said it many times. You can run Qt apps on Maemo and Symbian. Noone is going to remove that. Don't want to write platform specific app with DirectUI, use QWidgets and you will be fine

That was never the question It's the other way around (as Dui bases on Qt). I'll try to formulate the question as clearly and down to the point as possible:

Can Dui-based applications written for Maemo be deployed to Symbian, WinMo/CE without rewrites and ported to Desktop platforms with minimum effort ?


EDIT: Desktop editions were never claimed to do Dui, modified the question accordingly.

People constantly mix QT applications, dui, orbit in one sentense.

Sure. Libdui, is open source, multiplatform UI framework. It depends on QT. Certain parts depend on D-Bus, Socket, ICU, GStreamer. But it's possible to strip it during compilation of library. Compile libdui for symbian and you will not need to change a single line of code of your app

Something to be taken into account in this discussion is who is potentially affected by these layers on top of Qt. I mean, following the thread it looks as if all the developers were pushed to choose between plain Qt or DUI/Orbit.

If we put this in perspective, we have

- Web Runtime (cross-platform Maemo/Symbian probably with iPhone etc at an affordable extra cost).
- OpenGL ES apps lightly wrapped and also quite cross-platfom including again iPhone and others.
- QML, cross-platform wherever you have Qt. What is your opinion about this one?
- Should we add here "plain QGraphicsView"?, also cross-platform wherever there is Qt?
- The aforementioned plain Qt.
- At least in Maemo there will also be a noticeable % of "Other community supported", GTK+, SDL et al.

Now take all the developers that in one year time will be targetting Maemo. Start by Web Runtime and continue the list, leaving in each item the developers that will be happy with that technology.

What % do you think that will be left for the DUI/Orbit arena and what kind of profiles and applications do you expect from them?

NOTE: I don't have a crystal ball either but knowing your opinions will probably help understanding this debate and putting it in some context.

Something like 80-90% ?
Every app that likes to be a "first class citizen".

I'm a Qt desktop developer/user. I'd like to start hacking with Qt on mobile app(s) (but only first class citizen!). But I won't start, as long as I totally confused.
Which technology should I use in the future?
Will plain Qt be sufficient? Is QML the future? QGraphicsView? ItemViewsNG? Do I have to use Maemo/DUI and Symbian/Orbit separately?

As stated before. I'm confused. And as long as I don't know where Nokia is heading, I won't likely start hacking.