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

Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> schrieb:
> 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 ;-)).

Ok, here are a few more examples.

* As previously mentioned, a BSlider with MIDI-control. How this is 
useful? Get an affordable MIDI-controller like nanoKontrol [1] and 
start assigning sliders in applications to it. For example, in 
Wonderbrush: assign 3 sliders for colour (R, G, B) to contorl pen 
colour. Another for pen size, and one for zoom, etc. Actually, GIMP 
implemented this functionality, you can control many parameters in the 
program like colour via MIDI... but the beauty of allowing this with 
interfacekit-addons would be that it doesn't require the applications 
to implement it themselves, they would simply "inherit" the 
functionality from the interfacekit addon. Also, it doesn't have to be 
MIDI, it could be some other external sensor. Let it be some input from 
an attached microcontroller board and you get many interesting 
applications for hardware-hacking.
* The Menu bar "HUD" interface that is currently discussed in another 
thread. With add-ons, you could just try it out: override the default 
menu bar with a "HUD-enabled" one as an add-on. If you don't like it, 
throw it out again. If enough people like it, make it the default for 
Haiku, but even then those who can't stand it could go back to a simple 
menu bar.
* A font-picker could benefit in the same ways as a colour picker
* Progress bars or text labels could be extended to send data to 
external displays. Again, a hardware hacking idea.

I have a few more ideas. In the end, it comes down to 80/20-type 
situations. Some things would be useful for 80% of the users, and then 
it can just be integrated into Haiku. But other features are only 
useful for 20%, but for them it could still be awesome... an add-on 
approach would allow everyone to choose and pick what they like best. 
It can set off a lot of creativity and new user interface ideas.

> How so? It's exactly the same development steps, just that linking 
> libbe.so will take a bit longer.

It becomes really complicated if you want to combine unofficial changes 
done by several people. One person maybe provides a patch you like for 
a widget, and then another person a patch for a different widget... 
you'll have to merge the sources together by hand, and of course not 
forget the development happening on the official interfacekit sources 
and merge that together as well. That's quite tedious and requires some 
programming knowledge.

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

True. I've thought a bit over this, and I think it could be solved. 
What if the add-ons would be compiled objects, but still in a linkable 
format? And when you drop an add-on into the add-on folder it gets 
automatically linked together with the other add-ons to form a "user-
libbe"? I think the performance issues can be handled.

[1] http://www.korg.com/nanoseries2 (eferring to the "nanokontrol" of 
the three shown devices)

p.s. the original fGUI-website with some more details on it is actually 
still up here: http://www.stegemann.net/Old/Old/fGUI/index.html

Greetings,
Julian

Other related posts: