Active Topics
-
Extra softwares in Sailfish using CLI, repositories, etc (117)
to SailfishOS by nieldk - 1 day, 18 hrs ago -
Firefox with Leste (6)
to Maemo 7 / Leste by teroyk - 2 days, 14 hrs ago - more...
| The Following User Says Thank You to ajalkane For This Useful Post: | ||
|
2012-01-24
, 07:18
|
|
Posts: 2 |
Thanked: 0 times |
Joined on Jan 2012
|
#42
|
Originally Posted by ajalkane
Thanks.
Heh, I had no idea it worked like that. I assumed when headphones are plugged in, the ringing would come from headphones also. Seems almost like a bug.
I'll look if supporting that is possible, unless PR1.2 fixes the issue.
At first I naturally assumed that also, but after the first call I got on the bus the assumption was gone
Could also be a mistake between the chair and the keyboard or something fishy in the phone. I'm also missing calendar reminders from my Google Synced events. I might need to do a reset pretty soon. Hopefully that solves all the problems.
But still I would like to see this feature if possible.
|
|
2012-01-25
, 16:46
|
|
Posts: 1,313 |
Thanked: 2,977 times |
Joined on Jun 2011
@ Finland
|
#43
|
Opinions from those who would like rules based on wifi:
Would it be enough for rule to be based on what wifi you're connected to, or do you need rule on what wifis are near by?
I'm asking because the near by detection might be a bit of battery using due to bug (I think).
So I would rather just implement it based on if you're connected to named wifi.
EDIT: another thing. Is rules based on the WLAN name enough, or does anyone have real-life issues of having many different WLANs with same name? In that case there would be need to use WLAN id instead of name.
If there's no objections, I'm going forward with the assumption that the connected to WLAN and by using WLAN name only is sufficient. These are the simplest assumptions to implement. And in the case of connected to WLAN, the most power efficient.
Last edited by ajalkane; 2012-01-25 at 22:57.
Would it be enough for rule to be based on what wifi you're connected to, or do you need rule on what wifis are near by?
I'm asking because the near by detection might be a bit of battery using due to bug (I think).
So I would rather just implement it based on if you're connected to named wifi.
EDIT: another thing. Is rules based on the WLAN name enough, or does anyone have real-life issues of having many different WLANs with same name? In that case there would be need to use WLAN id instead of name.
If there's no objections, I'm going forward with the assumption that the connected to WLAN and by using WLAN name only is sufficient. These are the simplest assumptions to implement. And in the case of connected to WLAN, the most power efficient.
Last edited by ajalkane; 2012-01-25 at 22:57.
|
|
2012-01-26
, 05:26
|
|
Posts: 1,313 |
Thanked: 2,977 times |
Joined on Jun 2011
@ Finland
|
#44
|
Originally Posted by ajalkane
In a surprise move of unprecedented swiftness, Nokia Store claims version 1.2.0 has been put to the store. I can't see it yet, but I guess it should be there within few hours.
I have submitted version 1.2.0 of ProfileMatic to Nokia Store. Compared to the beta there came some changes as well.
Here's what's new compared to 1.1.0:
- Location conditions based on cell tower ids
- End time for condition
- Restore previous profile option
- Default rule
- UI/UX improvements
| The Following User Says Thank You to ajalkane For This Useful Post: | ||
|
|
2012-01-27
, 05:31
|
|
Posts: 1,313 |
Thanked: 2,977 times |
Joined on Jun 2011
@ Finland
|
#45
|
Here's beta version that supports condition's based on connected WLAN access points:
http://www.kolumbus.fi/arto.jalkanen...beta_armel.deb
I have limited possibilities myself to test this feature, as I have only home wlan.
http://www.kolumbus.fi/arto.jalkanen...beta_armel.deb
I have limited possibilities myself to test this feature, as I have only home wlan.
|
|
2012-01-28
, 06:39
|
|
Posts: 1,313 |
Thanked: 2,977 times |
Joined on Jun 2011
@ Finland
|
#46
|
Another day, another beta. Here's a beta version that supports setting BlueTooth mode:
http://www.kolumbus.fi/arto.jalkanen...eta2_armel.deb
I have an option there to set BlueTooth on and visible. But it doesn't seem to change the "Visibility" setting on the device. So that setting will likely be removed from the final version.
Last edited by ajalkane; 2012-01-28 at 06:46.
http://www.kolumbus.fi/arto.jalkanen...eta2_armel.deb
I have an option there to set BlueTooth on and visible. But it doesn't seem to change the "Visibility" setting on the device. So that setting will likely be removed from the final version.
Last edited by ajalkane; 2012-01-28 at 06:46.
|
|
2012-01-28
, 10:58
|
|
Posts: 81 |
Thanked: 44 times |
Joined on Nov 2009
@ Switzerland
|
#47
|
Originally Posted by ajalkane
What if the wifi connection is dropped and then enabled minutes later. I have flaky wifi support at work and wifi goes away occasionally. It would be bad to loose silent ringtone because phone dropped from a wifi.
So I would rather just implement it based on if you're connected to named wifi.
|
|
2012-01-28
, 11:54
|
|
Posts: 1,313 |
Thanked: 2,977 times |
Joined on Jun 2011
@ Finland
|
#48
|
Originally Posted by Arpa
That's a good point, and I've thought about it only a bit.
What if the wifi connection is dropped and then enabled minutes later. I have flaky wifi support at work and wifi goes away occasionally. It would be bad to loose silent ringtone because phone dropped from a wifi.
But the rules can be arranged so that the profile won't be changed from what it was. If the rule doesn't have 'restore profile' and no other rule that sets profile matches when connection is dropped, then the profile stays 'silent'.
Of course setting up your rules like that might not be convenient or even possible in some cases. I could put a timeout for the rule before it loses it's validity in case WLAN connection drops. Have you checked how long it takes until it reconnects? I'd appreciate answers from others who have experienced flaky connections too.
| The Following User Says Thank You to ajalkane For This Useful Post: | ||
|
|
2012-01-28
, 15:19
|
|
Posts: 1,313 |
Thanked: 2,977 times |
Joined on Jun 2011
@ Finland
|
#49
|
Originally Posted by ajalkane
I installed PR1.2 and with it, also visibility is changed. I can't anymore downgrade to PR1.1/1.0 so I need someone to confirm if it fails to change visibility status (I might have tested hastily).
I have an option there to set BlueTooth on and visible. But it doesn't seem to change the "Visibility" setting on the device. So that setting will likely be removed from the final version.
|
|
2012-01-28
, 17:36
|
|
Posts: 228 |
Thanked: 137 times |
Joined on Jan 2012
@ UK
|
#50
|
Originally Posted by ajalkane
I tried to install this, but it failed saying required packages not found, do i need to install something else first? Or remove the version I have from Ovi store?
Another day, another beta. Here's a beta version that supports setting BlueTooth mode:
http://www.kolumbus.fi/arto.jalkanen...eta2_armel.deb
I have an option there to set BlueTooth on and visible. But it doesn't seem to change the "Visibility" setting on the device. So that setting will likely be removed from the final version.
I'll look if supporting that is possible, unless PR1.2 fixes the issue.