Page 8 of 42 FirstFirst 123456789101112131415161718 ... LastLast
Results 71 to 80 of 415

Thread: Space Navigator PE Driver Development Thread

  1. #71
    FLAC sama's Avatar
    Join Date
    Feb 2006
    Location
    London, UK
    Posts
    1,375
    simple for me is no good, it's got to be hard

    what would you need a front end for?

    regarding the mechanism for switching contexts, I was thinking it would be better if the frontend somehow told the driver which context it should be in. I'm sure we can think of a few mechanisms to do this. That way, if the touchscreen is used to switch to a different screen, the context would also be switched.

  2. #72
    FLAC sama's Avatar
    Join Date
    Feb 2006
    Location
    London, UK
    Posts
    1,375
    I wonder how exec would behave if the exponential mode is on, and it the driver is sending something like this:

    exec.exe FAST_FORWARD (or whatever the command is)

    at 200Hz!

  3. #73
    inh
    inh is offline
    Maximum Bitrate
    Join Date
    Jan 2007
    Location
    Fort Riley KS
    Posts
    515
    Well, with the keymapping, you define what action you want to take on what skin page, or it can be universal for all skin pages, or it can have certain functions for certain skin pages, and then one default action for the rest.. I'm going to try to dig up that thread again. Why add in extra complexity when RR already features mechanisms for this

    as for the front end, it woul dbe great to just do a gesture, and have the lil app figure timings and such...

  4. #74
    inh
    inh is offline
    Maximum Bitrate
    Join Date
    Jan 2007
    Location
    Fort Riley KS
    Posts
    515
    this isnt THE thread i read, but it pretty much explains it..
    Context Sensitive Hotkeys? (PowerMate related)

  5. #75
    FLAC sama's Avatar
    Join Date
    Feb 2006
    Location
    London, UK
    Posts
    1,375
    Ah, I see what you're saying now. That's a good idea, I'll get it to spit out keys too so that can be used. In that case, you'd only define one context.

    Might still be worth including multiple contexts for other FE's. I wonder how many other front ends do this, if at all. Any idea anyone?

  6. #76
    inh
    inh is offline
    Maximum Bitrate
    Join Date
    Jan 2007
    Location
    Fort Riley KS
    Posts
    515
    Cool

    Yea i guess for other front ends it would be helpful to have the front end tell the driver what part of the skin it was on.. But i mean really, who uses other frontends?

    Cant wait for this to be released glovepie was great to play with the sapce nav in RR but a native driver will be 1000x better

  7. #77
    Super Moderator. If my typing sucks it's probably because I'm driving.... turbocad6's Avatar
    Join Date
    Oct 2004
    Location
    NY
    Posts
    6,234
    I think being able fine tune it is a good option for sure & I think gestures are a great idea, for example all the way up followed by an all the way down can trigger a predefined action I guess, but 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...

    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...

    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?


    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?


    wish I knew a bit about programming to be of more help... I am ordering one of these now finally

  8. #78
    SMKFree liquid_smoke's Avatar
    Join Date
    Aug 2003
    Location
    Chicago
    Posts
    4,842
    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.
    01101100 01101001 01110001 01110101 01101001 01100100 01011111 01110011
    01101101 01101111 01101011 01100101

    beer replenishment fund
    http://www.mp3car.com/vbulletin/rr-faq/
    mp3car live search

    i have joost invites, just hit me up for one.

  9. #79
    FLAC sama's Avatar
    Join Date
    Feb 2006
    Location
    London, UK
    Posts
    1,375
    First of all, thank you all for your valuable input. It's much appreciated.

    Quote Originally Posted by turbocad6 View Post
    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 View Post
    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 View Post
    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 View Post
    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 View Post
    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 View Post
    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 View Post
    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 View Post
    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 View Post
    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 View Post
    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 View Post
    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 View Post
    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.

  10. #80
    SMKFree liquid_smoke's Avatar
    Join Date
    Aug 2003
    Location
    Chicago
    Posts
    4,842
    cool, sounds good to me.


    Quote Originally Posted by sama View Post


    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.
    The text overlay is an idea, it would have to fade away or go away and not be persistent though. Maybe a gesture that shows you what context you are in?




    Quote Originally Posted by sama View Post
    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?
    No RR keeps the same window title, but the only time you would need to change the context for RR to something different would be when you have an embedded application running, like GPS or the webbrowser. I really cant think of anything else you would really need to have a different set of commands.
    RR is pretty easy to control as far as keyboard goes, LEFT, RIGHT, UP, DOWN and ENTER will navigate the whole app. I dont think in practice you with need to have different context on different standard screens in RR as they all can be controlled with those 5 keys. Only embedded apps would need a different context. If the driver app would accept commands from RR to switch the context everything would be golden on RoadRunner side of things.

    Quote Originally Posted by sama View Post
    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
    Yup, pretty much thats all thats needed and the ability to run an application with command line options.

    Quote Originally Posted by sama View Post
    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.
    I think all the top 3 FE's, RR, CF and SD (is there really anything else on the same level) all have some sort of keyboard control for all its functions. So i dont think this would even be necessary.


    will there be a mouse mode?
    01101100 01101001 01110001 01110101 01101001 01100100 01011111 01110011
    01101101 01101111 01101011 01100101

    beer replenishment fund
    http://www.mp3car.com/vbulletin/forumdisplay.php?f=93
    mp3car live search

    i have joost invites, just hit me up for one.

Similar Threads

  1. Questions!
    By Yellow-Snow in forum Mobile Impact
    Replies: 4
    Last Post: 06-10-2006, 05:18 PM
  2. iGuidance Font Size Fix summary thread
    By Viscouse in forum GPS
    Replies: 29
    Last Post: 03-28-2006, 06:21 PM
  3. Hot Chicks Thread - NOT WORK SAFE
    By ODYSSEY in forum Off Topic
    Replies: 1
    Last Post: 05-17-2005, 09:38 PM
  4. Replies: 3
    Last Post: 01-07-2004, 11:52 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •