ChameleonMini icon indicating copy to clipboard operation
ChameleonMini copied to clipboard

Make configs for button, LEDs and logmode switchable from global to slot-wise at runtime

Open Vrumfondel opened this issue 6 years ago • 9 comments

Wouldn't it make sense to have individual button-settings for each slot? Right now they seem to be global.

Vrumfondel avatar Nov 30 '18 09:11 Vrumfondel

Hi @Vrumfondel, whether this makes sense or not depends on your use-case. For example, if you want to use the buttons to switch through slots, a different button-setting for each slot could lead to the situation that you enter this slot by pressing a button, but you cannot leave it anymore (without terminal) since this slot has another button setting.

Anyways, this is already possible, you can simply change these lines and recompile.

geo-rg avatar Nov 30 '18 09:11 geo-rg

I see, and agree that use of global or individual settings depends on use-case. Then, what of making that configurable instead of only compile option?

Vrumfondel avatar Nov 30 '18 12:11 Vrumfondel

@Vrumfondel You mean something like introducing a command that changes the behavior at run-time?

This would be possible although there are some issues:

  1. If someone wants to change the behavior from "button setting non-global" to "button setting global", a rule has to be implemented which of the button settings is the new global one.
  2. Such a switch command should be implemented as well for the logmode (which is currently also global per default but changeable by compile option) and the LED settings (also global per default but changeable).

I will re-open this issue, change the title and mark it as enhancement. Feel free to hand in a patch, we'd appreciate it! :)

geo-rg avatar Nov 30 '18 12:11 geo-rg

Has this feature using the compiler-switches really been tested? To me it seems not to work - the settings are always global ......

Vrumfondel avatar Dec 03 '18 12:12 Vrumfondel

PR done .....

Vrumfondel avatar Dec 04 '18 09:12 Vrumfondel

working! many thx vrumfondel!

herrmanns avatar Jan 27 '19 16:01 herrmanns

another idea.

how about completely individual_configurable UID. maybe somebody of you guys have such solution already. my idea was to add the following (hopefully understanable)

[11] 22 33 44 55 66 77 Lbutton [12] 22 33 44 55 66 77 (that's of course possible already) Lbutton [13] 22 33 44 55 66 77 Rbutton (here starts the idea) Lbutton 13 [23] 33 44 55 66 77 Lbutton 11 [24] 33 44 55 66 77 Rbutton Lbutton 13 24 [34] 44 55 66 77 Lbutton 13 24 [35] 44 55 66 77 Lbutton_long Lbutton 13 [25] 35 44 55 66 77

Lbutton == one up Rbutton == one right Lbutton_long == one left

herrmanns avatar Jan 28 '19 16:01 herrmanns

Well, I think I get your idea, but I see a big problem in the usability: I don't really see a good way to feed back which byte of the UID is currently being changed - not even talking about the actual set UID.

The pure implementation is not a real issue ...

Vrumfondel avatar Feb 11 '19 08:02 Vrumfondel

hi vrumfondel,

yes, it is a bit tricky to show whats going on with just 2 LEDs. it may be possible to use the LEDs and "long button press" for it. and you have to store the current hex in your brainware :) or you are able to connect some raspi with display to read it out (if really necessary). in my use case i dont need to know that. the only thing which is important is that i know which "hex slot" is currently active to change.

herrmanns avatar Feb 11 '19 10:02 herrmanns