--===============0464884622== Content-Type: multipart/alternative; boundary="===============2317001676377998422==" --===============2317001676377998422== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable > 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 wi= th a gps for you either :/, my only question/concern is that it's doing loo= k 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 u= sing 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 hav= e a system with gps, cheap wifi and expensive g3 connectivity .. somethings= , like looking up the place name on the internet, may not be acceptible eve= n 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 :) > = > Petri Damst=C3=A9n wrote: > 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 sepa= rate 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 implemen= ting pretty much all the same things. > > = > Beat Wolf wrote: > any progress on this patch? > = > Beat Wolf wrote: > can this patch be asumed dead? I do have a GPS, I could try get it working to test the patch if there is s= till interest in getting this in. However, we really need to sort out geol= ocation services for KDE as a whole, re-inventing everything that Geoclue a= nd Marble have already figured out is not the best use of resources. - John ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://svn.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://svn.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 re= turns longitude and latitude, as the GPS backend would give that data but t= he IP one would not. Today, it's the other way around: a patch to add plac= e name and country information to the GPS geolocation data, as the IP geolo= cation gives this but GPS geolocation does not. > = > The only caveat is that I'm programming blind - I don't have a GPS receiv= er, and 'it compiles' is far from good enough. Hence, I need a volunteer t= o 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://svn.reviewboard.kde.org/r/592/diff > = > = > Testing > ------- > = > It compiles, and it looks alright. How pitiful is that? Given it's base= d 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 > = > --===============2317001676377998422== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable
This is an automatically generated e-mail. To reply, visit: http://svn.reviewbo= ard.kde.org/r/592/

On April 14th, 2009, 6:59 p.m., Aaron Seigo= wrote:

other tha=
n 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 b=
e in a local cache, but i'm going to guess that in a fairly typical &qu=
ot;i'm using gps" scenario one won't have an internet connecti=
on 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 wh=
ere 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 acce=
ptible 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 wh=
ile .. .. like when i see a patch like this :)

On April 15th, 2009, 1:47 a.m., Petri Damst=C3=A9n wrote:

Dataengin=
e 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 evaluat=
e all the other possibilities before doing rewrite (there were some wlan et=
c 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 p=
retty much all the same things.

On January 24th, 2010, 3:18 p.m., Beat Wolf wrote:

any progr=
ess on this patch?

On September 24th, 2010, 10:22 a.m., Beat Wolf wrote:

can this =
patch be asumed dead?
I do have a=
 GPS, I could try get it working to test the patch if there is still intere=
st in getting this in.  However, we really need to sort out geolocation ser=
vices for KDE as a whole, re-inventing everything that Geoclue and Marble h=
ave already figured out is not the best use of resources.

- John


On April 14th, 2009, 4:46 p.m., Andrew Coles wrote:

Review request for Plasma.
By Andrew Coles.

Updated 2009-04-14 16:46:26

Descripti= on 

Yesterday, I proposed a patch for using an IP geolocation se=
rvice that returns longitude and latitude, as the GPS backend would give th=
at 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 p=
oint where the fields returned are identical, /irregardless of whether IP o=
r GPS data is used/.  Specifically, the user gets:

- Latitude
- Longitude
- Accuracy
- Country Name
- Country Code
- City Name

Testing <= /h1> 
It compiles, and it looks alright.  How pitiful is that?  Gi=
ven it's based on the IP geolocation XML code, but using a reverse geoc=
oding rather than IP geolocation service, it should in theory work, but it =
really does need testing by someone with a GPS unit.

Diffs=

  • /trunk/kdereview/plasma/dataengines/geolocation/location_gps.h (954031)
  • /trunk/kdereview/plasma/dataengines/geolocation/location_gps.cpp (954031)

View Diff
--===============2317001676377998422==-- --===============0464884622== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel --===============0464884622==--