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

  • From: "François Revol" <revol@xxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Mon, 30 Mar 2009 02:34:59 +0200 CEST

> I don't have a particular opinion on Qt and I think that we need more
> developers writing more software and that will only happen when they
> work with tools they want to use on software that interests them.

We'll always get people saying "oh you don't have [Qt|GTK]? you don't
exist!" who want to use whatever IDE they are used to they think exists
everywhere.

> One of the difficulties with Haiku development is that you often feel
> you have to port or write utilities before you can write the actual
> software you wanted to write.

Yes, this has become increasingly more difficult as time passes.
Eve some years ago it was quite easy to port stuff, you'd just get the
CVS or release, fix the crappy autocrap code that wrongly detects
libfoo but fails at checking for libm, write a native backend/frontend
and be done with it.

Now for anything you need to port dozens of dependancies.
Just look at Gnash.
Swfdec is even worse dependancy-wise.

And coders tend to disregard native ports as useless and not wanted
because it would "clutter" their otherwise clean-thought-but-just-badly
-abstracted source tree. So they force Qt, GTK, Glib, Gstreamer,
libfoo, libbar on everyone.
That is the problem.

>
> But I do think we have to be careful about what is ported vs native.

Ported stuff can become native if correctly integrated.
OSS4 just publishes the mixer controls and the media node like native
ones.

> No disrespect to the people who ported VLC but in doing so it has
> reduced the feedback that the media kit gets.

Yes but it has enabled us to survive. Quite odd for a Media OS :)

> I don't know how to draw the line though, having parts of ffmpeg in
> Haiku has meant that Haiku can playback many many codecs we would
> never have had.

Well it's just used as a backend for the Media Kit, so it appears no
differently to native apps as other codecs.

> Porting a framework often gives us a cheap way to get software, some
> of which we really need but it also makes it difficult for us to
> stand
> out from the crowd in any meaningfull way.

It's not so much what we reuse, but how we reuse it.
Just look at SANE.
Appart a few "native" BeOS driver which actually each had their own
incompatible API, it is the default way to scan under BeOS, but noone
uses xsane or scanimage.
They use Sanity instead which uses SANE to do the work.
With the Translatorization I did, any app is able to scan by just
opening a special image file. (though I need to be reminded to add a
special ioExtension flag to tell the translator to refuse scanning for
apps only wanting non interactive loading; it'd be odd to have a
screensaver loading random image getting stuck on a scanner.)

Gnome is "just" starting to have a standardized API for scanning, and
it seems to not include this ability, so all apps have to be converted.
Though SANE was available on Linux before BeOS...

Same for GOCR, I don't recall seeing it integrated so oddly in Gnome :)

François.

Other related posts:

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