[haiku-development] Re: R1/a4 initial planning
- From: Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 01 Mar 2012 23:33:54 +0100
On 01.03.2012 23:01, Julian Harnath wrote:
[...] 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.
Haiku being open source, I fail to see the point - if the replacement is
better, it should be part of Haiku.
Also, you can just drop in new widgets to the libs folder, too, and all
applications can use it. That's no different than what MUI delivers,
too, only that libbe.so combines many widgets into one big library (no
harm done, it just improves application start time considerably).
Another advantage: it makes it easier to transition and develop the new
InterfaceKit.
Not at all. You still need fixed and stable interfaces to define the
functionality, and that is the hard part.
[...] especially in
Haiku, because it has this kind of add-on architecture in so many
places already.
Do not forget that add-ons are costly as they considerably add to the
startup time of applications (think Photoshop or Eclipse). It's just not
a good idea to use them where they don't make sense. And even if you
have an add-on capable infrastructure, it still makes sense to have the
defaults built-in because of that.
Qt with QML is where GUI APIs are currently developing towards. To be
honest, I simply don't understand the appeal to it; I find an integrated
approach a la Java FX 2 (vs. Script) much preferable -- why introduce a
really badly designed slow interpreted language to do a task as simple
as GUI handling? On top of that, why should developers learn a new
language just for that? A GUI *designer* certainly won't do the coding
either way.
I imagine a different approach to the new Interface Kit than to what Qt
does, anyway. I would like to extend the BControlLook basics to a more
object oriented approach of painters to further simplify creating
standard looking custom UI controls. I certainly would like to have a
more model based approach (why is there no button model in Qt, anyway?).
I think one can learn much more about good UI API design from Swing than
from Qt (with the possible exception of drag&drop, although I'm not
familiar with Qt's solution here, Swing's is really bad).
Bye,
Axel.
Other related posts:
