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

  • From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Mon, 30 Mar 2009 10:35:57 +0200 CEST

Karsten Heimrich <host.haiku@xxxxxx> wrote:
> Axel Dörfler schrieb:
> > 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.

A generic typed and persistent container is a pretty powerful tool.

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

That's not really the same thing, especially when communicating between
different apps.
BMessages are pretty much automatically back- and upwards compatible.
You don't need to change or recompile applications for that.

> If you need to communicate to
> an system app, you are free to use the platform specific code inside
> Qt too.

Again, this limits Qt as a cross platform API pretty much.

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

That's one out of two, but while it's indeed documented, it's not as
clear as calling the function in question. It's also the only occasion
I'm aware of that makes this differentiation.

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

Of course it's something you can blame Qt of. Every platform Qt runs on
supports IPC in one form or the other. Whether you can seemlessly talk
to system apps via Qt is another question, but talking to other Qt apps
should always be easily possible.

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

A QDataStream is like a file that cares about endianess, that's not
really comparable. And an interface for persistent objects can be used
for anything (like saving settings, sending objects over the network,
etc.) not just for archived BViews (which I haven't used outside of
replicants yet).
Flexibility is the key here, and this is what Qt is pretty good at,
too, at other places.

> > QThreadStorage is pretty limited, too, and for no obvious reason.
> You are free to file bug reports  ;)

I know; if I already had an account, I might have done so already :-)

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

That's not what I meant; moc often failed to correctly do its magic in
.cpp files.

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

That doesn't mean it was a good decision, it just means that you are
now pretty much stuck with it :-)

> > 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 was speaking of Embedded, not Extended, and as of 4.5 that still
seems to exist.

> > 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 don't need to, I only look at what's coming out to the customer.
There is no FBC protection in the headers, and they definitely did
break compatibility between releases several times.

Anyway, don't get me wrong; I like Qt. And it's better and more
complete than the Be API in most things. It's just not the perfect API,
even if it seems to improve over time.


Other related posts: