View Poll Results: What trigger you want to see next

Voters
163. You may not vote on this poll
  • Bluetooth device trigger

    35 21.47%
  • Screen state trigger

    14 8.59%
  • Calendar event trigger

    40 24.54%
  • Silent switch trigger

    32 19.63%
  • Headphones trigger

    19 11.66%
  • Signal strength trigger

    23 14.11%
Page 155 of 167 FirstFirst ... 55105145150151152153154155156157158159160165 ... LastLast
Results 3,081 to 3,100 of 3326
  1. #3081  
    Update: The latest version of the Save/Restore application includes support for Mode Switcher.

    Should be a welcome update for many of us. :-)
  2.    #3082  
    It seems that the GPS trigger is not working as I suspected because I were unable to test it. Will fix for Wednesday release. Now I just need to see why my phone was not getting GPS fix yesterday...
  3. #3083  
    Quote Originally Posted by sconix View Post
    Now I just need to see why my phone was not getting GPS fix yesterday...
    If it makes you feel any better, since yesterday my GPS thinks I'm about 80 miles north of where I actually am (130 km for those of you outside the US). I'll give it another day or two and see what it does. Hope I don't need an ambulance to find me in an emergency...
  4. bbroecker's Avatar
    Posts
    27 Posts
    Global Posts
    45 Global Posts
    #3084  
    Quote Originally Posted by sconix View Post
    I might have found a bug that could cause the cal event trigger to fail. Since usually the time notifications from WebOS comes second or two later that they are set, but sometimes they are just on time. And I did not take this into account the calevent trigger may give false positive for the trigger which causes the closing not to go through. This is the only thing I could think that could cause your problem. This is fixed in next release.
    Just wanted to confirm that the recent updates have fixed my problem with the Calendar Trigger. It is now closing properly when the calendar event ends.

    Thanks!!!
  5.    #3085  
    I am thinking that the locking state would also need a indicator in the top bar. But what I am not sure is that would be OK if I only set it to show ! in the place of + (modifiers) indicator or does it need to show both. My thinking is that when ever you lock the mode you know what modes are active and don't need the + sign anymore. Just a indicator to see that you still have mode locking on. Or if both need to be indicated then does anybody have good ideas? I mean showing both + and ! might look bit stupid.

    Or should I switch to colors? Set the status text (mode name / carrier) to red when mode is locked and to yellow when modifier modes active. Or something similar. Would it be better than the + / ! signs?
  6.    #3086  
    Quote Originally Posted by bbroecker View Post
    Just wanted to confirm that the recent updates have fixed my problem with the Calendar Trigger. It is now closing properly when the calendar event ends.

    Thanks!!!
    Thanks for letting me know since I was not 100% sure if the latest fix fixed your problem.
  7. #3087  
    Quote Originally Posted by sconix View Post
    I am thinking that the locking state would also need a indicator in the top bar. But what I am not sure is that would be OK if I only set it to show ! in the place of + (modifiers) indicator or does it need to show both. My thinking is that when ever you lock the mode you know what modes are active and don't need the + sign anymore. Just a indicator to see that you still have mode locking on. Or if both need to be indicated then does anybody have good ideas? I mean showing both + and ! might look bit stupid.

    Or should I switch to colors? Set the status text (mode name / carrier) to red when mode is locked and to yellow when modifier modes active. Or something similar. Would it be better than the + / ! signs?
    What about leaving the + as you have it now (for modified modesm which I really am used to now and really like) and adding the colors as you mentioned for the locking. (The colors would be useful even though I am not one for colorizing the whole top bar like some might enjoy)

    For more information on Sconix's (@therealsconix/@modeswitcher) webOS collective work... visit here.

    "Those convinced against their will are of the same opinion still." - Dale Carnegie
  8.    #3088  
    Quote Originally Posted by oakridge outdoors View Post
    What about leaving the + as you have it now (for modified modes) and adding the colors as you mentioned for the locking.
    So you mean that leave + for showing when modifier modes active and red color when current mode is locked? Sound good to me and actually I like this the most. If no other suggestions arise I think I go with this.
  9. #3089  
    Quote Originally Posted by sconix View Post
    So you mean that leave + for showing when modifier modes active and red color when current mode is locked? Sound good to me and actually I like this the most. If no other suggestions arise I think I go with this.
    Yep, that's what I was going for.
    I like it!

    For more information on Sconix's (@therealsconix/@modeswitcher) webOS collective work... visit here.

    "Those convinced against their will are of the same opinion still." - Dale Carnegie
  10.    #3090  
    Quote Originally Posted by oakridge outdoors View Post
    Yep, that's what I was going for.
    I like it!
    I release new version of the patch on Wednesday and it will have this, although I think I go with yellow color since it is not that "dangerous" its just so that user remembers to take the logging away.
  11. #3091  
    I don't mind the color idea, but to me something like (Sprint+) would connotate a locked mode nicely to me (using parentheses instead of a color). No offense but I am not a fan of colors in my UI, especially with the issues that can arise in different lighting conditions and brightness settings.
  12.    #3092  
    Quote Originally Posted by tobias funke View Post
    I don't mind the color idea, but to me something like (Sprint+) would connotate a locked mode nicely to me (using parentheses instead of a color). No offense but I am not a fan of colors in my UI, especially with the issues that can arise in different lighting conditions and brightness settings.
    Yes I am not a fan of colors neither, but for temporary things like the locking (it is only meant to hold the mode active longer than triggers allow in a special situations, for turning MS off completely should be done from the app activated toggle). So thats why I keep the + sign for modifier modes since they can be active long periods and its "normal". But the locking is temporary state and most likely can be forgot to leave on so the color is more stronger way to indicate that something "not normal" is on and requires users attention at some point.
  13. #3093  
    Quote Originally Posted by tobias funke View Post
    I don't mind the color idea, but to me something like (Sprint+) would connotate a locked mode nicely to me (using parentheses instead of a color). No offense but I am not a fan of colors in my UI, especially with the issues that can arise in different lighting conditions and brightness settings.
    You're always throwing out good ideas. I like that better than the colors too.

    Quote Originally Posted by sconix View Post
    But the locking is temporary state and most likely can be forgot to leave on so the color is more stronger way to indicate that something "not normal" is on and requires users attention at some point.
    Sconix: Maybe using the nice gesture tap features in your patches you could make the color/parenthesis a toggle option for those that would like color or not?

    For more information on Sconix's (@therealsconix/@modeswitcher) webOS collective work... visit here.

    "Those convinced against their will are of the same opinion still." - Dale Carnegie
  14.    #3094  
    Quote Originally Posted by oakridge outdoors View Post
    Your always throwing out good ideas. I like that better than the colors too.

    Sconxi: Maybe using the nice gesture tap features in your patches you could make the color/parenthesis a toggle option for those that would like color or not?
    Damit I miss read the thing, I replaced the + with ! and somehow dismissed the parentheses in my mind So now I understand the idea of putting the text in (). Damn now I don't know which way I should do it.

    But I think I go with the color for one reason: code simplicity. Adding text to the current carrier string without changing too much of the top bar code is a bit painful process. And adding another check for combination of + and () it would make ~10 lines of extra code. But if I keep the other as a separate color changing its only 3 lines. Hopefully it'll be ok, at least the locking is not normally on (at least should not be).
  15. #3095  
    Quote Originally Posted by sconix View Post
    Damit I miss read the thing, I replaced the + with ! and somehow dismissed the parentheses in my mind So now I understand the idea of putting the text in (). Damn now I don't know which way I should do it.

    But I think I go with the color for one reason: code simplicity. Adding text to the current carrier string without changing too much of the top bar code is a bit painful process. And adding another check for combination of + and () it would make ~10 lines of extra code. But if I keep the other as a separate color changing its only 3 lines. Hopefully it'll be ok, at least the locking is not normally on (at least should not be).
    I'll be okay with it either way even though I'd prefer the + for modified modes and the () for locked. If the other way (color) helps you achieve code simplicity, I've got no complaints.

    For more information on Sconix's (@therealsconix/@modeswitcher) webOS collective work... visit here.

    "Those convinced against their will are of the same opinion still." - Dale Carnegie
  16. #3096  
    Yeah I honestly don't use mode locking very often so whatever makes the code better sounds good to me.
  17.    #3097  
    Quote Originally Posted by tobias funke View Post
    Yeah I honestly don't use mode locking very often so whatever makes the code better sounds good to me.
    Yes and I don't think very many even use it, but its only there for those rare situations for example if you have time based activation and you know that for some reason that specific time you need the mode to be active longer than it is set so its just easier to be able to lock the mode than wait for it to close and then activate again manually. But since it is very easy to forget on it needs some indicator so thats why I am adding one. And the color really was much simpler addition so I went with that.
  18.    #3098  
    The current version still has couple stupid bugs left. These are fixed in next release. The bugs are:

    - Application trigger not always closing the mode.

    - Charger & wireless triggers delay option is not used in certain situations.

    - Typo was left into GPS trigger rendering it useless.

    Please keep reporting all problems. Its hard to believe that only one people was experiencing these problems
  19. #3099  
    Report on .40

    The reactivation of a headphone mode when the plug is pulled is fixed.

    However, there may be a minor problem with your initialization code. When I installed .40, a number of my modes with that were set to trigger on "one trigger", were updated to "All unique".

    Otherwise looks good so far.
  20.    #3100  
    Quote Originally Posted by ggarvey View Post
    Report on .40

    The reactivation of a headphone mode when the plug is pulled is fixed.

    However, there may be a minor problem with your initialization code. When I installed .40, a number of my modes with that were set to trigger on "one trigger", were updated to "All unique".

    Otherwise looks good so far.
    Hmm thats weird. At least there is no code that would update that setting. I have to check how something like that could happen.

Tags for this Thread

Posting Permissions