First of all, thank you all for your valuable input. It's much appreciated.
Quote: Originally Posted by
turbocad6 
since this thing is so sensitive & doesn't have a very solid center return, what are the chances of performing gestures accidentally? I think it might be good if gestures required a full travel one direction then another, so it would be very unlikely for a false gesture...
Yep, the threshold value is the amount to ignore before that axis kicks in. So the higher you set that value, the more you'll have to push/pull that axis to perform that action
Quote: Originally Posted by
turbocad6 also, it would be cool if gestures could be used with more than just 2 successive inputs, like for a control-alt-delete, could require an up/down/up/down for example...
I could see this getting pretty complicated to use if many gestures are implemented, but that just means more control for those who want it, & for those who want to keep it more simple, then gestures can be limited...
They can be. You'd define it something like:
GESTURE: TWIST+ | 100 | TWIST- | 100 | VERTICAL+ | 100 | VERTICAL- | 100 | ...
Which is a bit like a mortal combat special move... but there you go
Quote: Originally Posted by
turbocad6 I'm not sure I understand how this can be function changed depending on the screen it's in, but if that can be done in RR it would be awesome... I guess this is one of the advantages of writing your own program?
Tha's the idea, yep. The mechanisms to do this are something that I'm hoping to figure out in these discussions.
Quote: Originally Posted by
turbocad6 I have used the shuttle express which reminds me of this thing... one way it does progressive travel is through key presses, but the further through the axis the control is, the faster it repeats the key press, so a slight twist would press for a volume up say once every half second, & the further through the travel the faster they would repeat.... everything was set with a program that gave a nice user interface & had the ability to save different profiles... it could do different actions depending on the program it was used in, but nothing like changing functions depending on the screen.... I'm guessing this is going to be a matter of doing this only in roadrunner?
To begin with, I would imagine so, but having read what liquid_smoke has said below about doing it based on active window, this may not be the case.
Quote: Originally Posted by
turbocad6 wish I knew a bit about programming to be of more help... I am ordering one of these now finally
at last
Quote: Originally Posted by
liquid_smoke 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.
Good call. I did try a hybrid ini/xml format, so that I could gain structure and readability. I find that ini files are nicer to read than xml, but xml provides structure. You're right though about other programs using it, and that outweights the value of the structure element. Using prefixes for organsation as you've mentioned is the way to go.
Quote: Originally Posted by
liquid_smoke 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?
The idea I had there was that using a button would cycle through the gestures top to bottom. but then I wasn't sure how the user would keep track of the context they're currently in. I then thought that a mechanism is required to inform the user, like perhaps an overlay bit of text.
Quote: Originally Posted by
liquid_smoke 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.
exactly, especially when done blind. unless notification is there also, then I would say this is a no-go.
Quote: Originally Posted by
liquid_smoke 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
Interesting approch and I like it. However what of contexts that do not have an app window title? I mean, skins within RR say that do not embed an app? Does RR change it's title based on the skin page it's on?
Quote: Originally Posted by
liquid_smoke 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.
This is the approach I had in mind. Also, inh mentioned above that RR uses keyTBL and execTBL to allow context switching. So for RR, it looks like just pumping out some key presses from the driver may allow this to integrate with RR
Another way is to write a file somewhere, which tells the current context. This would allow many apps to get that info, but for FE's, this would require additional code.
I guess the ultimate way of making this work, is to request integration from FE writers.
Quote: Originally Posted by
liquid_smoke 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?
exactly, and pulse mode allows you to tweak how often to pulse by providing parameters for a range (start pulse rate and end pulse rate) and how to accelerate through that range (linear or exponential)
Quote: Originally Posted by
liquid_smoke 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.
agreed. I think starting with one mechanism, then changing as required is the best way to go.