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

  • From: Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Fri, 02 Mar 2012 17:49:56 +0100

On 02.03.2012 13:07, Julian Harnath wrote:
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.
> * [MIDI]

Sorry for being picky, but: for the MIDI slider controller, I would rather see a completely different approach of having the controls export some kind of explorable interface (like scripting, but maybe a bit more powerful) to make it accessible. This could also include other kinds of input (ie. special user interfaces for the blind, or whatever else you can think of).

* The Menu bar "HUD" interface that is currently discussed [...]

As pointed out there, this wouldn't be enough, you would need to change the interface of the menu first, in order to be able to provide additional information to make the feature useful at all.

* A font-picker could benefit in the same ways as a colour picker

I don't quite see how.

* Progress bars or text labels could be extended to send data to
external displays. Again, a hardware hacking idea.

Hm, and how would you decide which one to publish there? I would rather see something like this either using the accessibility framework mentioned above, and/or hook into the notification system -- which could work using a simple listener mechanism for such events.

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.

Again, I see little reason in doing so. I would even argue that this would be a) a rare case, and b) shouldn't be how you develop new stuff, as that one should play well with the existing stuff.

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.

It would impose a few additional requirements for the add-ons (like being in separate namespaces if they export anything, and somehow have different entry points that can be found to initialize them (I don't have any idea on how to solve this right now, but I have the feeling it should be possible, at least), but it sounds like this could be a solution to the problem -- which could always be utilized if all add-ons are loaded anyway (which isn't the case in all use cases, obviously).

Bye,
   Axel.

Other related posts: