The installation went fine here on xperia 10ii with latest sfos. I have noticed recently some issues with one addin for the when condition : network cells.
In the past, I was pressing register (not sure about the exact English as i am using the French version) and cells would be added. I have a ‘at home’ situation, I deleted it and reinitiated it. What I do is that I register cells every time the condition is not matched so I am adding the cells gradually that are around my home.
This was working nicely in the past. With latest version, I could add at this stage 4 cells but adding more is not working and while I can press “register”, it does not increment to 5 as it should (and used to).
What is tricky is not it works until a certain stage as I could add 4 cells…
By itself it is. But it’s just painfully uncompatible with my ambient.
Can you do a
dconf dump /desktop/jolla/theme/color
once with a normal-looking ambience, and once with an “unpleasant” one? We’re looking for a hex value of
#FFCC80
or thereabouts.
Unfortunately even after I added trailing slash as requested by error the output was empty in both cases.
But in output of
dconf dump /desktop/ | grep -A 5 "jolla/theme/color"
When wrong (Situation doesn’t change back to the previous Ambient background) I got
[jolla/theme/color]
highlight='#ffffcc80'
primary='#ffffffff'
secondary='#ffbababa'
secondaryHighlight='#ffc59d62'
and when proper Ambient
[jolla/theme/color]
highlight='#ff90a3fe'
primary='#ffffffff'
secondary='#ffbababa'
secondaryHighlight='#ff6f7fdc4'
I created an alternative Situation to retest if the upgrade import corrupted original Situation but it didn’t help.
For what it’s worth, Situations (current and previous versions) sets ambience just by calling “setAmbience” via dbus “com.jolla.ambienced” service and path to the ambience as an argument.
When wrong (Situation doesn’t change back to the previous Ambient background) I got
[jolla/theme/color] highlight='#ffffcc80' primary='#ffffffff' secondary='#ffbababa' secondaryHighlight='#ffc59d62'
and when proper Ambient
Well (ff)ffcc80 and (ff)c59d62 are Amber/Orange hues so that’s consistent (the first part is alpha ,where ff is fully opaque).
Where is that Stella Ambience from? Is that that ole Angry Birds one? What is the color code in /usr/share/ambience/stella/stella.ambience
(the exact name may vary)?
yes angry birds…
here it is :
,
“wallpaper” : “Jolla_Stella.jpg”,
“highlightColor” : “#FFCDE3”,
“secondaryHighlightColor” : “#BBFFCDE3”,
“primaryColor” : “#FFFFFF”,
“secondaryColor” : “#BBFFFFFF”,
“ringerVolume” : 70,
“favorite” : true,
“partnerSpace” : “partnerspace-stella”
Where is that Stella Ambience from? Is that that ole Angry Birds one? What is the color code in
/usr/share/ambience/stella/stella.ambience
(the exact name may vary)?
I’m lost how that is connected. I use custom Ambient. There is no Stella Ambient in `/usr/share/ambience/ on my X10.
Just to rule out the “wrong” color is actually in the ambience file somehow. Apparently not.
For me doing
dconf dump /desktop/ | grep -A 5 "jolla/theme/color"
is returning
[jolla/theme/color]
highlight='#ffffcc80'
primary='#ffffffff'
secondary='#ffbababa'
secondaryHighlight='#ffc59d62'
with the wrong accent color,
and
[jolla/theme/color]
highlight='#ff01bcf9'
primary='#ffffffff'
secondary='#ffbababa'
secondaryHighlight='#b001bcf9'
with the right one.
In my case it is SFOS “Three” ambience.
As you can see after I restart the phone it gets unselected from the list,
even though in the main list it still says it is selected.
If I switch to a different situation their ambience work correctly, and even better, if I switch back to the original situation the colors are now correct and the ambience is selected.
But to me this is a very insignificant problem, that only occurs after reboot and is super easy to fix, by just applying an ambience from the top menu. The WiFi list not updating/clearing old networks is much more problematic.
Attempt at fixing:
- Import
- WiFi scanning
Available here: Release Beta release 287 · pastillilabs/packages · GitHub
It appears at least the issue where a WLAN-scan based Situation does not deactivate when the network disappears has been solved.
And the other way around works too.
Nice!
Yes, same here. Situations based on WiFi scanning are working correctly. Thank you.
Thank you for the confirmations! I forgot to mention that I also may have fixed the issue with active Bluetooth connection detection. Not sure about it since couldn’t test it myself yet.
I’ve noticed a regression since the new sandboxing compatible version. I use a situation to turn off wifi and switch to 4G when I enable mobile data. However it now sometimes thinks I’ve enabled mobile data when I enable VPN.
However it now sometimes thinks I’ve enabled mobile data when I enable VPN.
Thanks for the report. By “sometimes”, do you mean that it does not happen always?
I’ll see if I can reproduce the issue. But in general the code to detect & control mobile data hasn’t really changed since the previous version. Whether that code is correct is another thing (Situations detects & controls mobile data via the “AutoConnect” property of the primary cellular context)…
I don’t think it always happens but I can’t say with 100% certainty. I’m using the Wireguard plugin from Openrepos if that helps.
I’m trying to achieve a situation scenario where when certain conditions are met (at night/asleep), situations app would turn off/kill Android Support.
Since systemctl start/stop aliendalvik
needs permission (I suppose this is why), it doesn’t work.
As a workaround im using systemctl --user restart lipstick
, instead.
So, I went for Sudo. Installed it and got it successfully configured. It works fine in Terminal without sudo password prompts. I even included Situations app in the sudoers file==>nemo ALL = NOPASSWD: /usr/bin/harbour-situations2application.
On the other hand, I have already made some shortcuts with qCommand
that worked fine, and added it to the sudoers file as well. However, I had to use : echo mypasswrd | sudo -S systemctl stop aliendalvik
for it to work. The same command didn’t work in Situations app though.
* sudo systemctl stop aliendalvik
didnt work in either.
Anyone knows a way?
If sudo is set up correctly, no password is needed. That’s what sudo is designed for.
On the other hand, there is a dbus command to control app support that dosn’t require root privileges, and that can be used in scripts.
BTW, I have been using Situations to stoo app support at night for many years.
If sudo is set up correctly, no password is needed
I agree. And I already have said that in terminal, i can issue sudo commands without password input. But! I believe that sudo misbehaves/doesnt work as intended in non-interactive contexts, such as when running from a graphical application or script.
there is a dbus command to control app support that dosn’t require root privileges
Please, do share then
BTW, I have been using Situations to stoo app support at night for many years.
Thanks mate!
+edit: possibly related:
Seems sudo behaves the same on SfOs with my configuration as it does elsewhere (prompts for the password once (or once in a while?)). Maybe there’s some other configuration that gets rid of pswd prompts completely(?)
My configuration :
Summary
## Same thing without a password
%wheel ALL=(ALL:ALL) NOPASSWD: ALL
## Uncomment to allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL
nemo ALL=(ALL) ALL
## Additional edits for specific privileged commands
nemo ALL = NOPASSWD: /usr/bin/dbus-send
nemo ALL = NOPASSWD: /bin/systemctl
nemo ALL = NOPASSWD: /usr/bin/connmanctl
nemo ALL = NOPASSWD: /usr/bin/qCommand
nemo ALL = NOPASSWD: /usr/bin/harbour-situations2application
You may use the following command to control app support without sudo
dbus-send --system --dest=com.jolla.apkd.control --print-reply /com/jolla/apkd com.jolla.apkd.control.controlService boolean:false
Simply use boolean:true as last argument to start app support at the end of the situation.