[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: Review Request: Add city and country resolution to GPS
From:       Petri_Damstén <petri.damsten () gmail ! com>
Date:       2009-04-15 8:47:17
Message-ID: 20090415084717.26951.27213 () localhost
[Download RAW message or body]



> On 2009-04-14 18:59:59, Aaron Seigo wrote:
> > other than a couple of code style comments, and that i can't test it with a gps \
> > for you either :/, my only question/concern is that it's doing look ups on the \
> > internet without checking to see if we're connected. it could be in a local \
> > cache, but i'm going to guess that in a fairly typical "i'm using gps" scenario \
> > one won't have an internet connection as well. should we query solid for network \
> > status? 
> > rambling off-topic here: i also wonder if we aren't going to want some "can use \
> > the internet for ..." settings somewhere for the case where we have a system with \
> > gps, cheap wifi and expensive g3 connectivity .. somethings, like looking up the \
> > place name on the internet, may not be acceptible even if there is g3 service? \
> > not a use case we actually have to deal with now, but it's something that pops \
> > into my head every once in a while .. .. like when i see a patch like this :)

Dataengine already checks network state but since it thinks gps does not need one it \
uses gps plugin. I think location -> place should be a separate plugin. It's not \
possible with current code though and I would like to evaluate all the other \
possibilities before doing rewrite (there were some wlan etc ideas as well). For 4.3 \
should it go like this, I'm not sure?

For 4.4 is geoclue out of the question? It seems that we are implementing pretty much \
all the same things.


- Petri


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/592/#review923
-----------------------------------------------------------


On 2009-04-14 16:46:26, Andrew Coles wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/592/
> -----------------------------------------------------------
> 
> (Updated 2009-04-14 16:46:26)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> -------
> 
> Yesterday, I proposed a patch for using an IP geolocation service that returns \
> longitude and latitude, as the GPS backend would give that data but the IP one \
> would not.  Today, it's the other way around: a patch to add place name and country \
> information to the GPS geolocation data, as the IP geolocation gives this but GPS \
> geolocation does not. 
> The only caveat is that I'm programming blind - I don't have a GPS receiver, and \
> 'it compiles' is far from good enough.  Hence, I need a volunteer to test it - \
> anyone? 
> Assuming it works, the geolocation data engine will then have reached the point \
> where the fields returned are identical, /irregardless of whether IP or GPS data is \
> used/.  Specifically, the user gets: 
> - Latitude
> - Longitude
> - Accuracy
> - Country Name
> - Country Code
> - City Name
> 
> 
> Diffs
> -----
> 
> /trunk/kdereview/plasma/dataengines/geolocation/location_gps.h 954031 
> /trunk/kdereview/plasma/dataengines/geolocation/location_gps.cpp 954031 
> 
> Diff: http://reviewboard.kde.org/r/592/diff
> 
> 
> Testing
> -------
> 
> It compiles, and it looks alright.  How pitiful is that?  Given it's based on the \
> IP geolocation XML code, but using a reverse geocoding rather than IP geolocation \
> service, it should in theory work, but it really does need testing by someone with \
> a GPS unit. 
> 
> Thanks,
> 
> Andrew
> 
> 

_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic