From: <phil_at_x-phobie.de>
Date: Wed, 02 Oct 2002 07:48:59 +0200

On Wed, 2 Oct 2002 03:18:03 +0200, Paul van der Heu <pvdh_at_xs4all.nl>
wrote:

>On Tue, 1 Oct 2002 08:12:30 +0200, Nielsen Linus (ext) wrote:
>
>>matter of assigning a function to a key, it is far more than that
>>(key-down/key-up, key combinations, persistent quick-screens...).
>
>So make a config file in a format like:
>
>key,function,up/down,duration,backlight on,release,revert on repeat
>
>for example
>
>F2,show_wps,down,500,yes,no,yes
>
>would bind showing the WPS to F2 when it is pressed down for 500 ms
>or more and it would stay in the WPS until pressed for more then 500
>ms again. It would also turn the backlight on if it is off
>
>F3,show_info,down,1000,yes,yes,no
>
>Would bind showing the info screen to F3 when it is pressed for more
>then 1000 ms and return to the previous screen straight after release
>of F3. The backlight stays in its current state
>

I see a few things here:
1.)
You introduce times. I assume that it is motivated by the example that
Björn posted here

>Take the recorder ON button as an example. In WPS, release of the ON
>button is used to go to the dir browser, unless another key was
>pressed while the ON key was down, or if the ON key was held down
>for > ~500ms.

But when you look at the code (screen.c line 142 and line 56) you'll
realize that actually no times but a repeat BUTTON_REPEAT event is
used to delay the display of the on_screen. (Otherwise I'd have
considered as a break of code design, anyway). As far as I know we
haven't had any situations where we needed something like the time
based revert feature that you introduced above. Although it may be
interesting I'd prefer not to implement it until we have a real use
for it. (BTW the times you mentioned here are too short to read
something :)) I want to avoid it because it introduces extra time
settings. As I pointed out we haven't had any time settings yet
because everything could be done with button events. Additional time
settings would complicate things a bit. But if we want it we could
extend the events by time events and have a time setting, as well.
Let's just delay it until we need it.

2.)
Your idea doesn't consider different states of the machine. We have
different key bindings when we are in wps and when we hit f2 in wps.
So we must switch the key bindigs according to the context. In my
button scheme code embryo I made the same mistake and thus had to
extend the file format by specifying the next key scheme to use.

3.)
If we want a button to set the volume straight to 70% we have to pass
a parameter to the function. So the file format must offer means to
specify it, too. Of course we could make a set_to_70_percent function
in the source code but we have so many adjustable values that I think
it is worth the effort to implement a mechanism that can pass values
directly.


4.)
I like your idea of the separating button names and their event
modifiers. That simplifies editing the file.

5.)
I don't see the necessity to handle backlight with every button event
differently. IMHO the existing mechanisms for handling backlight
settings are fully sufficiant. Of course we would have functions that
can modify these settings and these functions could be assigned to
button events.

Thank you for your inspiring ideas.

Phil
Received on 2002-10-02