|
Per your PM request.
I think if possible, you should try to strickly follow the standard ini format of Section, Key, Value
[SECTION]
key=value
There a few reason why i say this, one it being easier to read/edit and also more importantly easier for an external application to read and edit.
I can whip up an autoit script that would read and set all the values and also intergrate this into RR with nice graphics to visualy see what you are editing.
Others can do the same for there frontend also, or even make a stand alone app to do the same.
It looks like your using xml now, but in either case i dont think you should create a format but yet use an existing format.
Where the section would be the name of the context
[CONTEXT GLOBAL]
and the keys names specifly what you are editing
AXIS_PAN_X=binary, 0.1
ACTIONS_CONTEXT_SWITCH_UP=BUTTON_R
note i reversed the way it original was so the value is always on the right of the = sign
and also removed the [AXIS] section and put it as a prefix to the key
This way there aren't any duplicate section names that will confuse any .ini editor or external app that tries to read the file as to where to read/write data.
So everything that is under a specific context applies to that context until it reaches another context.
I see the CONTEXT_SWITCH action but im unsure of how this exactly would work.
Do i state what context i want to switch too?
like
CONTEXT_SWITCH=GPS
if so where would i state the gesture or button that activates this switch?
I have a few ideas on how the context switching should be done.
1. Manual switch where the context_switch would be tied to a specific button or gesture and overrides any other setting for that button or gesture.
When activated it would cycle to the next CONTEXT in the configfile, top to bottom in the order they are listed.
This could get click happy though and require multiple button presses to get to the context you want.
2. Another way would be for the app to look for window titles to determine what context it should be in.
I belive this is the best method but would require more work than the first.
So if i wanted to have my GPS context to only work if my gps application is in "focus" and not just found. It may look like this
[CONTEXT_GPS]iguidance
where "iguidance" is the apps window title
3. Another way would be for the app to accept command line switches that would switch the context.
So if im using my favorite frontend , Road Runner, i could have it send a command to the driver app to switch to the GPS context when i enter the gps screen and another command to switch back when i leave.
"RUN;driverapp.exe|CONTEXT_SWITCH GPS"
This would require a little bit of work for skinners, but i personally dont mind, others may balk at the extra work.
Im a little confused about what BINARY and PULSE modes are, and the difference between them.
I think, binary is a simple send key or action that happens once where pulse is kind of like a repeat mode? So If i have the letter K tied to a action with pulse it would send the letter K over and over until i stop the action?
in any case, whatever you decide to go with, the end result is the only thing that really matters.
Looking at the file, it seems the end result is what I would like, so if i had to sit and edit the config file in its current state i wouldn't mind at all.
Its not confuseing to me or anything, i just know i wouldn't be able to write a frontend to the configfile.
But in practice, once you get everything setup the way you like, you rarely if ever will touch the file again.
My biggest question that im still a little wondering about would be exactly how the context switching happens.
Ill post more if i come up with any ideas or questions.
|