[haiku-development] Re: R1/a4 initial planning

  • From: Julian Harnath <julian.harnath@xxxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Thu, 01 Mar 2012 23:01:52 +0100

Julian Harnath <julian.harnath@xxxxxxxxxxxxxx> schrieb:
> By the way, there already was such a development for BeOS.
> "fGUI", developed by Stegemann Inc. back then, was a layout library 
> for 
> dynamic GUIs [...]

So, nobody interested in this? (replying to myself here...)
I think it's a very interesting approach.

Furthermore, I think that using Qt's GUI-parts as the main GUI API is a 
step into the past, not into the future... let me explain what I mean.

In the end, Qt's GUI API is quite similar to the InterfaceKit, although 
Qt might be more modern and better architected in some parts. But 
*both* of them miss the opportunity to really use the power of object 

With fGUI (and its inspirational source, MUI from the Amiga), it is 
possible to extend the interface API in the same way you can extend the 
kernel with new drivers, or how you can extend the TranslationKit with 
new translators. Simply drop a UI component into a folder, and 
applications can use it.
But it gets more interesting than that: you can also replace existing 
widget classes. Imagine simply dropping a textview-class object file 
into a folder somewhere in /boot/home/config, and immediately this 
textview replaces the default textview in all applications. Without 
anything else, no recompiling, no editing... just a restart of the 
applications. And all the new textview has to do is implement the 
textview interface defined by Haiku. Why would you want to do that? 
Maybe because it's a better textview which has spellcheck and syntax 
highlighting built-in. Just like that, all applications in your system 
using textviews gain spellcheck and syntax highlighting. Just like 
adding a translator for a graphics format gives you the ability to use 
it instantly everywhere.
Imagine replacing the BSlider class with one that can listen to MIDI 
controlchange events. Immediately, every slider in any application in 
your system can be controlled via MIDI. Or, if we get a HTMLView in the 
future, you could just replace the default webkit-based one with 
another one based on Gecko or NetSurf, and just like that, it's 

All that could be as simple as dropping a file into a folder, like 
installing a translator. Of course, it could be more sophisticated and 
application-sepcific overrides could be supported as well, so you can 
set which widget classes are used to replace the defaults per 

Another advantage: it makes it easier to transition and develop the new 
InterfaceKit. Third-party developers can experiment with it and extend 
it with their own widgets (simple things or also complex things, e.g. a 
waveform-view for audio editors) and that on a basis that is much less 
intimidating than working on the Haiku-sourcecode itself.

Neither the old InterfaceKit nor Qt's GUI-parts allow any of this, at 
least not to my knowledge. To me, it just makes sense, especially in 
Haiku, because it has this kind of add-on architecture in so many 
places already. That's why I think that using Qt's GUI-part for Haiku 
would be a step into the past, not the future.


Other related posts: