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

  • From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Sun, 29 Mar 2009 15:22:44 +0200 CEST

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 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. Before DBus there was no way to talk to other apps
with the means of the Qt API AFAIK. I miss persistence (ie.
BArchivable).
QThreadStorage is pretty limited, too, and for no obvious reason.

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). 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).

> > 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.

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, 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 :-)

> > 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.

Bye,
   Axel.


Other related posts: