[haiku-development] Re: R1/a4 initial planning
- From: Julian Harnath <julian.harnath@xxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 02 Mar 2012 13:07:43 +0100
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:
