[haiku-development] Re: R1/a4 initial planning
- From: Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 02 Mar 2012 11:22:13 +0100
On 03/01/2012 11:51 PM, Julian Harnath wrote:
Axel Dörfler<axeld@xxxxxxxxxxxxxxxx> schrieb:
Haiku being open source, I fail to see the point - if the replacement
is better, it should be part of Haiku.
"Being better" is not always a one-dimensional property.
True enough.
For spellcheck in a textview, it might be true, you could just add that
to Haiku itself. But what about other examples? E.g. replacing a
Webkit-based HTMLView with one based on Gecko, it's hard to say which
is better, it's more based on personal preference.
Another example where it's not so simple: it would be nice for Haiku to
have a colour-picker widget. [...]
Those are indeed much better examples. In the case of an HTML view,
though, it would be a very complex thing to implement, as such a view
shouldn't just be a black box, but give access to the DOM, too. IOW the
implementation may get so complicated that an alternative is never going
to happen.
As for the color picker, yes, I can see that this can be useful,
although that's pretty much the only control I can think of (with my
obviously limited imagination ;-)).
By the way, with the reasoning "if it's good, it should be just added
to Haiku" you could just as well remove translators or tracker add-ons
and make them simply fixed built-in.
Sure. It's always a trade off, and Tracker add-ons, like translators,
are only ever loaded when actually needed; they don't add to the launch
time of the application. Granted, a color picker probably wouldn't do
that either, but having everything as add-ons would just be insane.
Not at all. You still need fixed and stable interfaces to define the
functionality, and that is the hard part.
Of course, but incremental changes of implementation can be done
easier, because it's simpler to try out new things without replacing
the enttire libbe.
How so? It's exactly the same development steps, just that linking
libbe.so will take a bit longer. There is the additional benefit of
changing libbe.so directly that you can limit its availability to a
single app, instead of messing with all your apps when placing the
add-on into an add-on folder.
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.
However, MUI did it long ago already on much slower hardware than what
we have today, and it worked...
You are comparing apples and oranges here: On the Amiga, there is no
runtime linking stage. Everything works via function pointers from a
global entry point. So having add-ons is much less costly (but still
noticeable due to having to load all the add-ons at some point).
Believe it or not, MUI was always one of the slowest of the Amiga GUI
frameworks which is why I never really used it, and usually preferred
native (ie. gtlayout based) solutions.
Bye,
Axel.
Other related posts:
