[haiku-development] Re: Haiku, Qt and apps, oh my!

  • From: Karsten Heimrich <host.haiku@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Sun, 29 Mar 2009 17:30:00 +0200

Hi,

Axel Dörfler schrieb:

Hi Karsten,

Karsten Heimrich <host.haiku@xxxxxx> wrote:

Axel Dörfler schrieb:

Stephan Assmus <superstippi@xxxxxx> wrote:
it's beautifully designed and is just as nice or nicer as the Be API, and much, much more complete.
Well, while I've been exposed to the Qt API, I actually found many holes in its design, especially when it comes to multi-threading, inter 
-app communication, asynchronous messaging, etc.

Care to elaborate more on this?
First of all, there doesn't seem to be anything equivalent to a BMessage. All you have are slots/signals
Thats true, and obviously there is no need for them. Since i guess BeOS was the only system that implements it like this, i wouldn't support it either. But if you need to pass your own data around inside your app, you can do this. It just needs two lines of code, one to declare it as meta type and one to register it and you are able to pass it around as with BMessage (in Signals and Slots). I'm not sure, but i guess this works also over DBus. If you need to communicate to an system app, you are free to use the platform specific code inside Qt too. 

 and inherited methods, and
it's not always clear whether it's asynchronous (QWidget::update()) or synchronous (QWidget::repaint()). It's also strange that some events are only available as slots, and others are only available via inheritance (like closing a window). The distinction is not really intuitive, at least.
I see no difference when using Invalidate() and Draw(...), and it's documented properly in Qt as well. So?
Before DBus there was no way to talk to other apps with the means of the Qt API AFAIK.
Nothing that is Qt to blame for. Since these standards depend on the platform, they had to wait before doing a decision. 


I miss persistence (ie. > BArchivable).
What would you use it for? I've seen a bunch of BeOS app, 99 % not using that feature. If you need to instantiate a UI, you are free to use the runtime QUILoader. Everything else can be stored in QDataStream. 


QThreadStorage is pretty limited, too, and for no obvious reason.


You are free to file bug reports  ;)
I also don't particularly like that it works around C++ limitations the way it does, and the moc tool usually doesn't manage to correctly parse source files (you usually need to move classes needing Q_OBJECT into their own header to make it work correctly).
If its inside your cpp, just put an #include "foo.moc" in your .cpp, it's properly documented. 

 Why not use Objective-C
instead? It already delivers what Qt is trying to do with C++ but even much more powerful (even if it's syntax is at least questionable). 

Since its a c++ framework? The decision was made 15 years ago  :)
The whole UI must run in a single thread in Qt, for example. 
Depends on what the supported platform provides.
At least not in 4.4 which is what I know a bit now. It specifically mentions in its threading docs that you must not use any UI classes within threads. And it wouldn't even make sense to use platform depended features in this way, as this pretty much works against the benefits of a cross platform API.
Also the differences between Qt and Qt embedded, and this whole not well integrated window surface stuff doesn't sound convincing to me. 

There is no Qt Extended anymore.
I understand Qt is a grown API as well, but in some area it definitely needs some more love. Since Qt does not really care about backwards compatibility a lot, 

Uhhh, bold statement. You can't imaging whats going on.

 I think this is all solvable, though. Hopefully

it's just a matter of time.


Stephan Assmus <superstippi@xxxxxx> wrote:

By now, VLC has switched over to Qt and the GUI is much better.
Actually, I don't like the Qt UI of VLC a lot. I think it's clumsy, overloaded, and hides useful functionality behind too many clicks. The only thing I like better there is the easily available aspect ratio setting. At least I don't consider this as a good example.
This is a moot argument, it all depends on the app developer. There is no way to blame Qt for the app design.
That's not what I wanted to say with this: I don't blame Qt for this, I think it's just a bad example from gaining something of a Qt port :-) 

Sure, i know what you meant. Couldn't resist. :)
And having seen the Qt VLC sources, I know there is just another hole in the Qt API to be filled (fast/native QImages, and support for video overlays). Not sure if they did already improve this for 4.5. 
There has been a lot addressed for 4.5.0


Nice to hear, and I definitely need to have a look at that, anyway.


As I said, feel free to report anything that bugs you.


Regards,
Karsten

Other related posts:

  1. Home
  2. haiku-development
  3. Archive
  4. 03-2009