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 149 of 167 FirstFirst ... 4999139144145146147148149150151152153154159 ... LastLast
Results 2,961 to 2,980 of 3326
  1. #2961  
    Sconix, I'm now on 1.4.5 and experiencing a Wi-Fi bug with MS. I have a World Mode that triggers when I disconnect from my home wifi network and it turns off the wifi radio. Well what happened was when I switched my phone to USB mode and then turned off USB mode, world mode triggered and turned off wifi. And since I have not been able to turn on wifi with MS, device menu, wifi settings, or Quick System Tasks. Only a hard reboot fixes this problem.
  2.    #2962  
    Quote Originally Posted by tobias funke View Post
    I like the change to only update modified settings. Not seeing the volume pop up on every single mode change will be pretty cool. :-)

    I also have a bug related to the app trigger. The associated app is closed but the mode is not closing as it should. I did the report problem thing.
    Yes I copied the charger trigger closing code so thats why application trigger only closes on normal modes not modifier So this is fixed in next release.
  3.    #2963  
    Quote Originally Posted by gollyzila View Post
    Sconix, I'm now on 1.4.5 and experiencing a Wi-Fi bug with MS. I have a World Mode that triggers when I disconnect from my home wifi network and it turns off the wifi radio. Well what happened was when I switched my phone to USB mode and then turned off USB mode, world mode triggered and turned off wifi. And since I have not been able to turn on wifi with MS, device menu, wifi settings, or Quick System Tasks. Only a hard reboot fixes this problem.
    If I understood correctly that when coming out of USB mode it detect wifi disconnect even it should not. I will have to test this and many other things what happens when going to USB mode and coming back. Some trigger might need special handling on that situation. Sadly the log you send did not show this event, but hopefully I can reproduce this.
  4. #2964  
    Don't know if it had been told later, but when my PrPrPr+ $was$ $charging$ $and$ $enter$ $in$ $powersaving$ $mode$ ($i$.$e$ $shut$ $off$ $the$ $screen$) $a$ $few$ $second$ $later$ $it$ $power$ $on$ $the$ $screen$ $in$ $a$ $sort$ $of$ &$quot$;$half$ $brightness$&$quot$; $and$ $shut$ $down$ $1mn$ $later$ $the$ $screen$.
    When charging with TouchStone, the second wake up never end by totally shuting down. It stays on half brightness. Need to push the power button twice for the palm to enter in screen light saving mode.
  5.    #2965  
    Quote Originally Posted by Schmurtz View Post
    Don't know if it had been told later, but when my PrPrPr+ $was$ $charging$ $and$ $enter$ $in$ $powersaving$ $mode$ ($i$.$e$ $shut$ $off$ $the$ $screen$) $a$ $few$ $second$ $later$ $it$ $power$ $on$ $the$ $screen$ $in$ $a$ $sort$ $of$ &$quot$;$half$ $brightness$&$quot$; $and$ $shut$ $down$ $1mn$ $later$ $the$ $screen$.
    Does not happen to me, but the current version had a bit too many requests send on display management which may have caused something like that. The next version has small changes in the turn off / always on management which hopefully takes that away for you.
  6. #2966  
    Hey Sconix. Looking forward to the next RC release with the few bug fixes....

    Two things today...

    #1 is a question about expected behavior in a unique situation...

    Generically: What happens when a Modifier Mode is running on top of a Normal mode (No Mode Blocking) and a different Normal mode (with Blocking) is triggered....? Further, when that Modifier Mode is supposed to end (and the current Normal Mode has "Block Other Modes" in place, is the Modifier Mode blocked from ending? The specific situation is probably more clear:

    Home normal mode is running (wifi ssid trigger and no mode blocking)... From 9pm-5am (chosen randomly), I use a dim-screen modifier mode to lower display brightness down to 6% for better evening viewing...

    I go to bed at 11pm (with dim-screen still in effect) and my Bedside normal mode kicks in (TS and timed trigger) to turn off various radios and set the "On TS" setting to off. It also sets screen brightness to 1% (which I believe occurs and overrides dim-screen mode from 6% - but I could be wrong about that). Bedside Mode is set to Block (all) "Other Modes".

    When I wake up at 6am, bedside mode is still in effect - as expected. Removing from TS ends "bedside" and initiates Default mode (wifi turns on). Wifi turning on then triggers Home Mode (also as expected). However, each of the past two mornings I have noticed that when I arrived at work, the 'dim screen' mode is still in effect (even though it should have triggered off at 5am...)

    Is this because I have bedside set to block other modes. Expanding on this... does "Block other modes" even block modifier modes from Ending if they were ON when the mode started? If so, I can work around this, but I just wanted to confirm expected behavior. I grant you that this is probably a relatively unique circumstance.

    #2 is actually a suggestion for the Top Bar Mode Switcher patch....

    I'm not sure everyone would like this one since it is a slight change from normal WebOS UI menu design, but I'll throw it out there for you and others to comment on...

    Would it be possible to use colored text in the MS patch to show which modes were active (rather than just the ON/OFF label)? You could use GREEN text for the name of the (single) MS Normal Mode that is active and maybe YELLOW or BLUE for each of the Modifier Modes that might be active at a particular time. It would be a great visual indicator of current state because it takes just a little extra focus to look down the ON/OFF label list to assess what the current normal and modifier modes are? Just an idea, you can take it or leave it.

    Thanks. John
  7.    #2967  
    Quote Originally Posted by greenawayj View Post
    Hey Sconix. Looking forward to the next RC release with the few bug fixes....

    Two things today...

    #1 is a question about expected behavior in a unique situation...

    Generically: What happens when a Modifier Mode is running on top of a Normal mode (No Mode Blocking) and a different Normal mode (with Blocking) is triggered....? Further, when that Modifier Mode is supposed to end (and the current Normal Mode has "Block Other Modes" in place, is the Modifier Mode blocked from ending? The specific situation is probably more clear:

    Home normal mode is running (wifi ssid trigger and no mode blocking)... From 9pm-5am (chosen randomly), I use a dim-screen modifier mode to lower display brightness down to 6% for better evening viewing...

    I go to bed at 11pm (with dim-screen still in effect) and my Bedside normal mode kicks in (TS and timed trigger) to turn off various radios and set the "On TS" setting to off. It also sets screen brightness to 1% (which I believe occurs and overrides dim-screen mode from 6% - but I could be wrong about that). Bedside Mode is set to Block (all) "Other Modes".

    When I wake up at 6am, bedside mode is still in effect - as expected. Removing from TS ends "bedside" and initiates Default mode (wifi turns on). Wifi turning on then triggers Home Mode (also as expected). However, each of the past two mornings I have noticed that when I arrived at work, the 'dim screen' mode is still in effect (even though it should have triggered off at 5am...)

    Is this because I have bedside set to block other modes. Expanding on this... does "Block other modes" even block modifier modes from Ending if they were ON when the mode started? If so, I can work around this, but I just wanted to confirm expected behavior. I grant you that this is probably a relatively unique circumstance.

    #2 is actually a suggestion for the Top Bar Mode Switcher patch....

    I'm not sure everyone would like this one since it is a slight change from normal WebOS UI menu design, but I'll throw it out there for you and others to comment on...

    Would it be possible to use colored text in the MS patch to show which modes were active (rather than just the ON/OFF label)? You could use GREEN text for the name of the (single) MS Normal Mode that is active and maybe YELLOW or BLUE for each of the Modifier Modes that might be active at a particular time. It would be a great visual indicator of current state because it takes just a little extra focus to look down the ON/OFF label list to assess what the current normal and modifier modes are? Just an idea, you can take it or leave it.

    Thanks. John
    1) Yes the blocking block also mode close triggers. Not sure if it should though. At least I don't want to keep a list what modes were started before mode with blocking is started, but I can set it easily so that it won't block mode closing. Its just a matter of what is expected in that situation. Now with more thinking I think it should only block starting of modes NOT closing. And the lock current mode in the mode menu should lock both since its meant to "halt" some situation for longer period when you know that mode is closing soon but want it to stay. To that I am also thinking should it check triggers after that lock is removed or no. So feedback about these two situations are welcomed so I know how they should be.

    2) I am not a color person my whole theme is basically black and white. So I am not too eager to do this. And since the current way is mainly like it is so that it suits the default look of the UI. But as always its easy for someone to make a patch that adds colors.
  8. #2968  
    Sconix - Just a thought. I have noticed that if I am on a phone call or there is a alert waiting to be answered on my phone such as a text, email or calender alert when the time of day trigger should go off to change the mode nothing happens. Is it set up to work that way or have I done something wrong? It would be nice if there was something in place that would recognize that your call has ended and it is past the trigger time that a pop up would come up to change modes once your call has been completed or once your alerts were cleared off.

    Thoughts?
    My History of the last 10 years with Sprint! Palm Pre is by far the BEST!

  9.    #2969  
    Quote Originally Posted by huffman01 View Post
    Sconix - Just a thought. I have noticed that if I am on a phone call or there is a alert waiting to be answered on my phone such as a text, email or calender alert when the time of day trigger should go off to change the mode nothing happens. Is it set up to work that way or have I done something wrong? It would be nice if there was something in place that would recognize that your call has ended and it is past the trigger time that a pop up would come up to change modes once your call has been completed or once your alerts were cleared off.

    Thoughts?
    Its something how WebOS works internally that when on phone call the system request are not working normally. At some point I need to start testing this that is there some way MS can detect these situations. And I am sure that there is some way, but then I at least need to test and see what exactly are those situations that cause problems. So this is on my TODO list after 1.0.0 is out with other fine tuning things as is the handling of situation for mode changing when already mode change is in progress.
  10.    #2970  
    The new release should be out withing next 6 hours. I had to leave something out from this release and therefore next release might happen as soon as on Friday or Saturday. For what is in the next release see the wiki. So things that was left to next release:

    - GPS trigger (I know I promised this, but its almost working already in my current development version so should finally be in next release).

    - Testing of USB mode and if it causes problems.

    Then there is something that I had to leave out for now (the code is there, but disabled):

    - Per account IM status when messaging plugins installed. This was due to limitation that those plugins need storing of passwords and I don't want to store clear text passwords in MS config. So this will have to wait until WebOS api or messaging plugins allow login with stored password etc.

    Then stuff that has been reported and are known but I will handle most likely after 1.0.0. These should not cause any problems only unexpected behavior on some situations.

    - Phone call and other system operations might interrupt or prevent mode change.

    - Handling / testing of situations where mode changing is requested while previous change is still being finished.

    - Handling updating of launcher when there is another trigger while popup is being shown.

    I also changed the wifi ssid and calendar event match text to be case insensitive. If somebody sees this as a very bad thing then report. Otherwise I think this is better and will save a lot of miss configuration issues.
    Last edited by sconix; 08/12/2010 at 10:41 AM.
  11. #2971  
    Quote Originally Posted by sconix View Post
    1) Yes the blocking block also mode close triggers. Not sure if it should though. At least I don't want to keep a list what modes were started before mode with blocking is started, but I can set it easily so that it won't block mode closing. Its just a matter of what is expected in that situation. Now with more thinking I think it should only block starting of modes NOT closing. And the lock current mode in the mode menu should lock both since its meant to "halt" some situation for longer period when you know that mode is closing soon but want it to stay. To that I am also thinking should it check triggers after that lock is removed or no. So feedback about these two situations are welcomed so I know how they should be.
    I guess either scenario makes sense depending on how you think about it. When I select Block, I might really mean I don't want ANY changes while that mode is active. I'm imagining that too many options might be bad for usability...but maybe in the Triggers-Block Mode setting you can change "Modifier Modes" to "Modifier Modes - All" (to block starts and stops) and add "Modifier Modes - Start" (which would not block modifier modes from stopping if their trigger ended). None of this discussion applies to normal modes since only one can be "On" at a time.

    Personally, I like the idea of 'check triggers' when the lock is removed in Mode Menu...

    Quote Originally Posted by sconix View Post
    2) I am not a color person my whole theme is basically black and white. So I am not too eager to do this. And since the current way is mainly like it is so that it suits the default look of the UI. But as always its easy for someone to make a patch that adds colors.
    That's OK. I thought the UI design change might be too much anyway. My eyes aren't so great any more so I really have to look closely to tell ON from OFF on the right side of that drop down --- maybe even "ON" is only needed when on.... and OFF would be left blank for those modes which are not running? Sorry, I'm really just a "visual cues" type of guy?

    Anyway, thanks for allowing us to be part of your creative process in both of these cases.
  12. #2972  
    I think it makes sense to have MS immediately check triggers when Trigger Locking is disabled.

    I also agree with the change to the case-sensitivity of wifi/calendar triggers.

    Along the idea from the poster above about colors identifying which mode is active: I think the main thing I would like to know sometimes is whether or not I am in modified settings just by looking at the phone, without having to open a menu.

    Idea: what if the mode name was modified with a + in the top bar if a modifier mode is active? So "Home" would switch to "Home+", or something along those lines. Maybe this is not feasible, but just an idea.
  13. #2973  
    Quote Originally Posted by sconix View Post
    If I understood correctly that when coming out of USB mode it detect wifi disconnect even it should not. I will have to test this and many other things what happens when going to USB mode and coming back. Some trigger might need special handling on that situation. Sadly the log you send did not show this event, but hopefully I can reproduce this.
    Yes that's partially correct. The other part is that when MS turns off wifi, it cannot be turned on unless a hard reboot is done. I'll reproduce it again and then I'll send you the log.
  14. #2974  
    Quote Originally Posted by tobias funke View Post
    Idea: what if the mode name was modified with a + in the top bar if a modifier mode is active? So "Home" would switch to "Home+", or something along those lines. Maybe this is not feasible, but just an idea.
    I like that!

    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
  15. #2975  
    Quote Originally Posted by gollyzila View Post
    Yes that's partially correct. The other part is that when MS turns off wifi, it cannot be turned on unless a hard reboot is done. I'll reproduce it again and then I'll send you the log.
    I get this with many of the radio settings... sometimes they get 'stuck'. Bluetooth is the biggest offender, but I've had it happen with wifi and roam only as well. But I cannot reproduce it on command, usually it works the way it is supposed to, at least for me. I've believed it to be a WebOS thing but I have no way of knowing for sure.
  16.    #2976  
    Quote Originally Posted by tobias funke View Post
    I think it makes sense to have MS immediately check triggers when Trigger Locking is disabled.

    I also agree with the change to the case-sensitivity of wifi/calendar triggers.

    Along the idea from the poster above about colors identifying which mode is active: I think the main thing I would like to know sometimes is whether or not I am in modified settings just by looking at the phone, without having to open a menu.

    Idea: what if the mode name was modified with a + in the top bar if a modifier mode is active? So "Home" would switch to "Home+", or something along those lines. Maybe this is not feasible, but just an idea.
    At least I would like to neither some kind of mark like + or then italic text or something for mode name to show that it is modifier. I will add something to next release of the patch.
  17.    #2977  
    Quote Originally Posted by gollyzila View Post
    Yes that's partially correct. The other part is that when MS turns off wifi, it cannot be turned on unless a hard reboot is done. I'll reproduce it again and then I'll send you the log.
    But the turning of wifi is related to USB mode or no? Since if its not then its WebOS fault. If its related to USB mode its still WebOS fault, but then I can go somehow around it like delaying initialization after USB mode or detecting USB mode etc. But this has not happen to me yet so without additional logs etc. can't say anything sure.
  18. #2978  
    Quote Originally Posted by sconix View Post
    At least I would like to neither some kind of mark like + or then italic text or something for mode name to show that it is modifier. I will add something to next release of the patch.
    Tobias Funke's "Mode Name +" suggestion works in all cases where a Normal Mode is active, but not when default has a Modifier in place... It would be cool if you could add a "+" to the Carrier String!!!
  19.    #2979  
    Quote Originally Posted by greenawayj View Post
    Tobias Funke's "Mode Name +" suggestion works in all cases where a Normal Mode is active, but not when default has a Modifier in place... It would be cool if you could add a "+" to the Carrier String!!!
    Its no problem to make it so that also after carrier string there is + sign when modifiers are on. So far this is the best idea and if I don't come up with anything else this is what is in next mode menu patch release.
  20. #2980  
    One more suggestion... It's now probably worth updating the OP in this thread to link to the WIKI... Currently...

    For current bugs and upcoming features can be seen here
    ... still dumps to your webpage which references "See the Wiki" but doesn't link.

Tags for this Thread

Posting Permissions