[haiku-development] Re: R1/a4 initial planning
- From: Stephan Aßmus <superstippi@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 02 Mar 2012 21:41:59 +0100
Hi,
Am 02.03.2012 13:07, schrieb Julian Harnath:
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.
I think the examples all work only in theory. In practice, applications
target specific behavior and bugs. Even just a different order of events
triggered by controls may screw things up for the application. In my
experience, the interaction between framework and application code takes
a significant amount of testing. Working out the kinks usually means
relying on a particular behavior.
* 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.
* WonderBrush uses a custom control for sliders.
* How would you even configure what MIDI channels map to which slider
without application support?
* What might work better is when WonderBrush would expose the parameters
via scripting.
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.
I haven't looked at the implementation in GIMP, but isn't there some
kind of configuration interface for this? Where would that go? How could
it be moved from the aplication to a generic place?
Best regards,
-Stephan
Other related posts:
