GNOME Bugzilla – Bug 740379
Respond when location services are disabled
Last modified: 2015-08-23 17:45:05 UTC
Created attachment 291016 [details] in-app notification mockup Location services can be globally disabled by the user. Right now, Maps doesn't seem to react to this. Some things that could be done if location services are disabled: * Don't show the blue dot that indicates the current location. * When maps is launched, show an in-app notification (see attached mockup). * If maps is being launched for the first time, show a view of the whole earth. Otherwise, show the last viewed location.
Oh, and: * When the find location button is pressed, show a modified version of the in-app notification: "To find your location, turn on location services."
Created attachment 291021 [details] in-app notification mockup After a bit of discussion on #gnome-design, the following seems like a better approach (ignore the previous comments): * Don't show the blue dot that indicates the current location. * When maps is launched, show the last viewed location. If it is being launched for the first time, show a view of the whole earth. * When the find location button is pressed, show an in-app notification (mockup attached).
Thanks for doing this Allan! Will get on it when time allows!
The behaviour in comment #2 sounds good to me!
(In reply to comment #2) > Created an attachment (id=291021) [details] > in-app notification mockup > > After a bit of discussion on #gnome-design, the following seems like a better > approach (ignore the previous comments): > > * Don't show the blue dot that indicates the current location. > > * When maps is launched, show the last viewed location. If it is being > launched for the first time, show a view of the whole earth. > > * When the find location button is pressed, show an in-app notification > (mockup attached). Thanks! In 2) "show the last viewed location", would that be the last map bubble indicating a place that has been shown? Or the latitude/longitude/zoom of the last maps window? Or should it be the last known location through geoclue?
(In reply to comment #5) ... > In 2) "show the last viewed location", would that be the last map bubble > indicating a place that has been shown? Or the latitude/longitude/zoom of the > last maps window? Or should it be the last known location through geoclue? I think the goal would be to return to the previous view shown. Therefore: the the latitude/longitude/zoom of the last maps window.
Some more comments here (taken from Debian Bug #769955, where I was confused why locations didn't work): 1. The button "Go to current location" is not greyed out or otherweise inactive if geolocation has been disabled. 2. No UI feedback at all AFAICT that geolocation is disabled and/or a hint where to enable it. 3. On a related note, I might add: if the user explicitly clicks on "Go to current location" that might override their general privacy policies. A user might not want the system to generally know where they are, but clicking that button implies consent IMHO. Point 2 is partly addressed in bullet point #3 of comment #2. Personally, I think having an in-app notification is fine, but the "Go to current location" should be inactive as well and probably have a pop-up hint about it. And finally: It would be great if gnome-maps could dynamically react to the Locations On/Off toggle in the Privacy Configuration applet. AFAICT, you have to restart maps to take a change there into account.
Thanks! We are er working on this and it will be takwn care off for 3.16 and maybe we can backport to 3.14 as well! Thanks for reporting here!
Thanks! (In reply to comment #7) > Some more comments here (taken from Debian Bug #769955, where I was confused > why locations didn't work): > > 1. The button "Go to current location" is not greyed out or otherweise > inactive if geolocation has been disabled. > This is fixed in master now. How can I help to get this into Debian? Should it be backported to 3.14 or earlier? > 2. No UI feedback at all AFAICT that geolocation is disabled and/or a > hint where to enable it. What are you looking for here? Some kind of error message if we fail to connect with geoclue? In the same style as a message if the privacy setting prohibit it? > > 3. On a related note, I might add: if the user explicitly clicks on "Go > to current location" that might override their general privacy policies. > A user might not want the system to generally know where they are, but > clicking that button implies consent IMHO. > > Point 2 is partly addressed in bullet point #3 of comment #2. Personally, I > think having an in-app notification is fine, but the "Go to current location" > should be inactive as well and probably have a pop-up hint about it. > What do you mean with pop-up hint? Would it be ok if the button was sensitive, but when pressing it the in-app notification appears and the button goes in-active? > And finally: It would be great if gnome-maps could dynamically react to the > Locations On/Off toggle in the Privacy Configuration applet. AFAICT, you have > to restart maps to take a change there into account. So I have a question here. The privacy configuration setting. Is that 'org.gnome.system.location.enabled' that we are talking about? Aday: Is it ok for an app to listen to that explicitly or might it change? Otherwise maps could listen to that and enable/disable the button depending on it.
(In reply to comment #9) > (In reply to comment #7) > > Some more comments here (taken from Debian Bug #769955, where I was confused > > why locations didn't work): > > > > 1. The button "Go to current location" is not greyed out or otherweise > > inactive if geolocation has been disabled. > > This is fixed in master now. How can I help to get this into Debian? > Should it be backported to 3.14 or earlier? For Debian, a backport to 3.14 would help, though I cannot guarantee it will get included, but so far, Gnome stable point releases have had a high chance to be accepted. > > 2. No UI feedback at all AFAICT that geolocation is disabled and/or a > > hint where to enable it. > > What are you looking for here? Some kind of error message if we fail to connect > with geoclue? In the same style as a message if the privacy setting prohibit > it? Hrm, right so there are three states I guess: 1. Geolocation works and is allowed via privacy settings 2. Geolocation works but is not allowed via privacy settings 3. Geolocation does not work, but is allowed via privacy settings I thought about state 2, but possibly a different notification would be appropriate for state 3. I generally meant that, yes, there should be some notification or error message if the user wants to go to their current location but cannot, due to either state 2 or 3. > > 3. On a related note, I might add: if the user explicitly clicks on "Go > > to current location" that might override their general privacy policies. > > A user might not want the system to generally know where they are, but > > clicking that button implies consent IMHO. > > > > Point 2 is partly addressed in bullet point #3 of comment #2. Personally, I > > think having an in-app notification is fine, but the "Go to current location" > > should be inactive as well and probably have a pop-up hint about it. > > What do you mean with pop-up hint? I meant a mouse-over hint, I believe "tooltip" is the correct technical term? > Would it be ok if the button was sensitive, but when pressing it the in-app > notification appears and the button goes in-active? That is the other option, making it slightly more accesible I guess. I believe the Gnome design/HIG people should chime in on what is appropriate here. > > And finally: It would be great if gnome-maps could dynamically react to the > > Locations On/Off toggle in the Privacy Configuration applet. AFAICT, you have > > to restart maps to take a change there into account. > > So I have a question here. The privacy configuration setting. Is that > 'org.gnome.system.location.enabled' that we are talking about? As far as I am concerned, yes. > Aday: Is it ok for an app to listen to that explicitly or might it change? > Otherwise maps could listen to that and enable/disable the button depending on > it. Well, currently the button is always enabled, but unless geoclue is found on startup, it does nothing. So my reading (without looking at the code) is that some geoclue initialization would be needed on top once enable/disable state changes, possibly.
(In reply to comment #10) [snip] > > > > This is fixed in master now. How can I help to get this into Debian? > > Should it be backported to 3.14 or earlier? > > For Debian, a backport to 3.14 would help, though I cannot guarantee it will > get included, but so far, Gnome stable point releases have had a high chance to > be accepted. Ok! Will fipple it in on the gnome-3-14 branch! > > > > 2. No UI feedback at all AFAICT that geolocation is disabled and/or a > > > hint where to enable it. > > > > What are you looking for here? Some kind of error message if we fail to connect > > with geoclue? In the same style as a message if the privacy setting prohibit > > it? > > Hrm, right so there are three states I guess: > > 1. Geolocation works and is allowed via privacy settings > 2. Geolocation works but is not allowed via privacy settings > 3. Geolocation does not work, but is allowed via privacy settings > > I thought about state 2, but possibly a different notification would be > appropriate for state 3. > > I generally meant that, yes, there should be some notification or error message > if the user wants to go to their current location but cannot, due to either > state 2 or 3. > Right. The tricky part is what message to give. Something like: "Failed to connect to the geoclue location service" ? And have additional console logs if run with MAPS_DEBUG=1 > > > 3. On a related note, I might add: if the user explicitly clicks on "Go > > > to current location" that might override their general privacy policies. > > > A user might not want the system to generally know where they are, but > > > clicking that button implies consent IMHO. > > > > > > Point 2 is partly addressed in bullet point #3 of comment #2. Personally, I > > > think having an in-app notification is fine, but the "Go to current location" > > > should be inactive as well and probably have a pop-up hint about it. > > > > What do you mean with pop-up hint? > > I meant a mouse-over hint, I believe "tooltip" is the correct technical term? > > > Would it be ok if the button was sensitive, but when pressing it the in-app > > notification appears and the button goes in-active? > > That is the other option, making it slightly more accesible I guess. I believe > the Gnome design/HIG people should chime in on what is appropriate here. > Yes, I guess so. Thanks! > > > And finally: It would be great if gnome-maps could dynamically react to the > > > Locations On/Off toggle in the Privacy Configuration applet. AFAICT, you have > > > to restart maps to take a change there into account. > > > > So I have a question here. The privacy configuration setting. Is that > > 'org.gnome.system.location.enabled' that we are talking about? > > As far as I am concerned, yes. > > > Aday: Is it ok for an app to listen to that explicitly or might it change? > > Otherwise maps could listen to that and enable/disable the button depending on > > it. > > Well, currently the button is always enabled, but unless geoclue is found on > startup, it does nothing. So my reading (without looking at the code) is that > some geoclue initialization would be needed on top once enable/disable state > changes, possibly. I have changed this now on master. It doesn't get enabled until you get an actual location update. But yes, that is what I have in a wip-branch, first check enable/disable and listen for change, then init geoclue. But Zeeshan, geoclue maintainer seem to thing I should not listen to the setting directly, but instead react to a dbus message error that I should get when location service is disabled. So we will see where we end up.
(In reply to comment #11) > Right. The tricky part is what message to give. > > Something like: > "Failed to connect to the geoclue location service" ? > > And have additional console logs if run with MAPS_DEBUG=1 Personally, I would say that "geoclue" is an implementation/platform detail that shouldn't be exposed to the user, so just "the location service" would be fine as a user-facing GUI message, but more diagnostics on stderr would be helpful.
Created attachment 292091 [details] [review] Add LocationServiceNotification
Created attachment 292092 [details] [review] Check and react if location service is off
Created attachment 292093 [details] [review] mapView: Only show userLocation when enabled
Cast of service off/on: https://www.youtube.com/watch?v=5zbSyi24HVM&feature=youtu.be Cast of service fails: https://www.youtube.com/watch?v=IVezq5oKbpM&feature=youtu.be
(In reply to comment #16) > Cast of service off/on: > https://www.youtube.com/watch?v=5zbSyi24HVM&feature=youtu.be > > Cast of service fails: > https://www.youtube.com/watch?v=IVezq5oKbpM&feature=youtu.be Looks great! Two comments: * "Failed to connect to location service" doesn't mean much to me. What has happened here? How is a user supposed to react? Ideally, an error should indicate to resolve the issue. * Seems like you are making the locate button insensitive there...? I'm not sure that's desirable - if it doesn't work, we can show one of these in-app notifications. Otherwise it looks permanently broken.
(In reply to comment #17) > (In reply to comment #16) > > Cast of service off/on: > > https://www.youtube.com/watch?v=5zbSyi24HVM&feature=youtu.be > > > > Cast of service fails: > > https://www.youtube.com/watch?v=IVezq5oKbpM&feature=youtu.be > > Looks great! Two comments: > > * "Failed to connect to location service" doesn't mean much to me. What has > happened here? How is a user supposed to react? Ideally, an error should > indicate to resolve the issue. > > * Seems like you are making the locate button insensitive there...? I'm not > sure that's desirable - if it doesn't work, we can show one of these in-app > notifications. Otherwise it looks permanently broken. Thanks for feedback! So ok. There are three distinct cases of geoclue not being available that I've encountered. 1) Switched off by settings 2) Failed to make a DBus "connection", this might mean that geoclue is not installed, that it is installed wrongly or that there is some permissions issue. 3) Geoclue reports to error to us, but we never get any location updates. So 2) Should really only happen if your distribution does not mess up. But it can occur if you want to try Maps out and attempt to build it for yourself. I have seen 3) myself on some systems. And 1) is what we are addressing here. So, yes. I agree with you about the message for 2). I am not sure what information we could give there. "Talk with your system administrator?" - "Have you installed geoclue?" I think it is tricky and would love some help. At the moment when we encounter 3) the button will never go sensitive, because we wait for an update from geoclue before we make it sensitive. We could have a timeout and make the button sensitive with a message about 'timeout' I guess. And yes I currently make the button insensitive after showing a notification. I think I misunderstood that for desired behavior. I wanted foremost a sensitive button to indicate that there is a "current location" and you press the button to go to it. Am I understanding you correctly that you want the button sensitive if there is a current location or if there is a messate to show? Thanks again!
For 3) it should be "Geoclue reports no error to us, but we never get any location updates"
(In reply to comment #18) ... > 1) Switched off by settings In that case, show: https://bug740379.bugzilla-attachments.gnome.org/attachment.cgi?id=291021 > 2) Failed to make a DBus "connection", this might mean that geoclue is not > installed, that it is installed wrongly or that there is some permissions > issue. I assume that maps requires geoclue, so this should never really happen, or be quite rare. We're probably in problem reporting territory here. You could show a message - "Oops, something technical has gone wrong" - or (and I don't really know how this works) trigger a problem report. > 3) Geoclue reports to error to us, but we never get any location updates. Hard to comment on this without knowing what the error is likely to be on the geoclue side, but you could show a message like for 2. Again, this is problem reporting - it's a bug. ... > And yes I currently make the button insensitive after showing a notification. I > think I misunderstood that for desired behavior. I wanted foremost a sensitive > button to indicate that there is a "current location" and you press the button > to go to it. Am I understanding you correctly that you want the button > sensitive if there is a current location or if there is a messate to show? I would always keep the button sensitive, and show messages if it is pressed and doesn't work for some reason.
(In reply to comment #20) > (In reply to comment #18) > ... > > 1) Switched off by settings > > In that case, show: > https://bug740379.bugzilla-attachments.gnome.org/attachment.cgi?id=291021 > > > 2) Failed to make a DBus "connection", this might mean that geoclue is not > > installed, that it is installed wrongly or that there is some permissions > > issue. > > I assume that maps requires geoclue, so this should never really happen, or be > quite rare. We're probably in problem reporting territory here. You could show > a message - "Oops, something technical has gone wrong" - or (and I don't really > know how this works) trigger a problem report. Yeah, I don't think apps should be handling installation/distro issues so I'd not show user any messages about this or if we do, a very generic one like Allan suggested above. > > 3) Geoclue reports to error to us, but we never get any location updates. > > Hard to comment on this without knowing what the error is likely to be on the > geoclue side, but you could show a message like for 2. Again, this is problem > reporting - it's a bug. This is not exactly a bug. Its a matter of geoclue failing to find your location and that is not a bug since geoclue can't possibly guarantee that it will always find your location.
Created attachment 294302 [details] [review] Add LocationServiceNotification
Created attachment 294303 [details] [review] Check and react if location service is off
Created attachment 294304 [details] [review] mapView: Only show userLocation when enabled
So this is rebased against master. And new behavior: The button is only disabled during the intial state where we connect to geoclue and location service is enabled. If location service is disabled we show the notification with button link to privacy panel. If location service fail we show an error message. This should never happend, really. But for now show a generic "this failed message". If location service is enabled, but takes more than 5 seconds, pressing the button will show "Position not found", until a position is found, if it ever is. How about that?
Casty: https://www.youtube.com/watch?v=Xe_oF47sijk&feature=youtu.be
Created attachment 294305 [details] [review] Add LocationServiceNotification
Created attachment 294306 [details] [review] Check and react if location service is off
Created attachment 294307 [details] [review] mapView: Only show userLocation when enabled
Attachment 294305 [details] pushed as a912b6c - Add LocationServiceNotification Attachment 294306 [details] pushed as a2d149f - Check and react if location service is off Attachment 294307 [details] pushed as 0f1d986 - mapView: Only show userLocation when enabled
Fantastic, thanks Jonas!