You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(96) |
Dec
(85) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(29) |
Feb
(13) |
Mar
(5) |
Apr
(2) |
May
(3) |
Jun
(8) |
Jul
|
Aug
|
Sep
|
Oct
(19) |
Nov
(9) |
Dec
(3) |
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2006 |
Jan
|
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
(12) |
Dec
(2) |
2007 |
Jan
(2) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Graham <gr...@4o...> - 2007-02-20 21:34:58
|
I have uploaded a few things now. Some features were not working for me and seemed to have some obvious fixes: Set/Clear Destination was not working, nor were new places being saved. The stop script was never called gpsd doesn't need the "-f" option anymore. I also uploaded my changes for nested folders. I believe this should not affect anyone not using the feature. Put a folder with it's own independent maps.txt file in the profile base maps folder and it will be added to the map list. The new maps.txt doesn't need to know which folder it is in. Hope that makes sense. Graham ztep wrote: >> I finally have some time to look at Qpegps again, and have built your >> new version with tile support but am not having much luck with gpsd at the >> moment. >> > > I'm glad to read your email (I was starting to think that noone reads this > mailing list) > > >> I can't update to the latest (2.34) since I am getting no response from >> the berlios server at the moment - would you send me your ipk to get me >> going? >> > > I have uploaded it to sourceforge under Misc_Utilities package. > > >> When I am able to test properly I will also be trying my nested folders >> addition which should still inter-operate nicely with all the other >> features, but I 'll test it before going further. >> > > I think so. > > >> A couple of things I have noticed, in the default start script: >> > > Thanks for looking at it I changed the script in a previous version, but I > forgot to change it on the final one. > > >> 1. gpsd is still started with -s and -p options - latest gpsd should only >> need the device without a switch - "gpsd /dev/ttyS3" >> > > In fact, it should be: gpsd -f /dev/ttyS3 > > >> 2. The default script needs to concatenate the lines related to the "stty" >> call, otherwise the current terminal is affected, not /dev/ttyS3 which is >> what is intended. >> > > I have removed this part because as long as I read gpsd now test and > configure the correct port speed. > > I have uploaded this changes along with other bugs that I found to svn. > > >> Also a couple of comments on your excellent Google maps page - a couple of >> things don't seem to work properly on Firefox (haven't tried anything >> else) - replacing "innerText" with "innerHTML" in the script seems to fix >> this. There also seem to be a couple of stray "</td>" items at the end of >> the map "<div>" element. >> > > I will look at it next week. Thanks for the feedback. > > >> Finally, have you any idea why Firefox keeps it's busy cursor on having >> display the complete map results from the script? I can't work that one >> out at the moment. >> > > I don't use Firefox, so I can help you, Why not ask this question on oesf > forums (http://www.oesf.org/forums/index.php?showtopic=21217&hl=) > > >> Sorry of the slightly off qpegps topic notes. >> > > I think on that page as part of qpeGPS project. > > ztep > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Qpegps-devel mailing list > Qpe...@li... > https://lists.sourceforge.net/lists/listinfo/qpegps-devel > > |
From: Graham <gr...@4o...> - 2007-02-15 20:17:05
|
Hi, back again, I just updated to your latest small changes which solved something which was confusing me - I have being trying my nested folders, which was working fine except for tile maps, which were ignored. I thought it was my problem, but it was that the code I was using expected "TILE" in the file and I had "TILED" copied from your map page. sorted now and it all seems to work well to me. I have got over my problem with gpsd but something which annoys me slightly (not qpegps problem) is that it automatically switches to SIRF binary mode, and doesn't switch back at the end. I have some other software I use occasionally, which doesn't used gpsd and appears to expect NMEA only. However that is a question for the gpsd developers. ztep wrote: > >> 1. gpsd is still started with -s and -p options - latest gpsd should only >> need the device without a switch - "gpsd /dev/ttyS3" >> > > In fact, it should be: gpsd -f /dev/ttyS3 > In fact, no, the manual states that "-f is deprecated and may be removed in a future version. Each command-line argument will be treated as a device to be probed for the presence of a GPS" so the command line only needs the app name and the device. > >> 2. The default script needs to concatenate the lines related to the "stty" >> call, otherwise the current terminal is affected, not /dev/ttyS3 which is >> what is intended. >> > > I have removed this part because as long as I read gpsd now test and > configure the correct port speed. > Good point, and makes things much more simple now. Is there any reason why the stop script isn't called when the Client is destroyed? It looks like this will only happen when the application is quit. The script is there, it is a shame not to use it! I'll do a little more testing now I have it working properly and then upload my alterations for nested map folders in a little while. Graham |
From: ztep <zt...@gm...> - 2007-01-13 17:21:24
|
> I finally have some time to look at Qpegps again, and have built your > new version with tile support but am not having much luck with gpsd at the > moment. I'm glad to read your email (I was starting to think that noone reads this mailing list) > I can't update to the latest (2.34) since I am getting no response from > the berlios server at the moment - would you send me your ipk to get me > going? I have uploaded it to sourceforge under Misc_Utilities package. > When I am able to test properly I will also be trying my nested folders > addition which should still inter-operate nicely with all the other > features, but I 'll test it before going further. I think so. > A couple of things I have noticed, in the default start script: Thanks for looking at it I changed the script in a previous version, but I forgot to change it on the final one. > 1. gpsd is still started with -s and -p options - latest gpsd should only > need the device without a switch - "gpsd /dev/ttyS3" In fact, it should be: gpsd -f /dev/ttyS3 > 2. The default script needs to concatenate the lines related to the "stty" > call, otherwise the current terminal is affected, not /dev/ttyS3 which is > what is intended. I have removed this part because as long as I read gpsd now test and configure the correct port speed. I have uploaded this changes along with other bugs that I found to svn. > Also a couple of comments on your excellent Google maps page - a couple of > things don't seem to work properly on Firefox (haven't tried anything > else) - replacing "innerText" with "innerHTML" in the script seems to fix > this. There also seem to be a couple of stray "</td>" items at the end of > the map "<div>" element. I will look at it next week. Thanks for the feedback. > Finally, have you any idea why Firefox keeps it's busy cursor on having > display the complete map results from the script? I can't work that one > out at the moment. I don't use Firefox, so I can help you, Why not ask this question on oesf forums (http://www.oesf.org/forums/index.php?showtopic=21217&hl=) > Sorry of the slightly off qpegps topic notes. I think on that page as part of qpeGPS project. ztep |
From: Graham <gr...@4o...> - 2007-01-11 22:54:41
|
Happy New Year, I finally have some time to look at Qpegps again, and have built your new version with tile support but am not having much luck with gpsd at the moment. I can't update to the latest (2.34) since I am getting no response from the berlios server at the moment - would you send me your ipk to get me going? When I am able to test properly I will also be trying my nested folders addition which should still inter-operate nicely with all the other features, but I 'll test it before going further. A couple of things I have noticed, in the default start script: 1. gpsd is still started with -s and -p options - latest gpsd should only need the device without a switch - "gpsd /dev/ttyS3" 2. The default script needs to concatenate the lines related to the "stty" call, otherwise the current terminal is affected, not /dev/ttyS3 which is what is intended. Also a couple of comments on your excellent Google maps page - a couple of things don't seem to work properly on Firefox (haven't tried anything else) - replacing "innerText" with "innerHTML" in the script seems to fix this. There also seem to be a couple of stray "</td>" items at the end of the map "<div>" element. Finally, have you any idea why Firefox keeps it's busy cursor on having display the complete map results from the script? I can't work that one out at the moment. Sorry of the slightly off qpegps topic notes. Graham ztep wrote: > Merry Christmas!! > > I have uploaded a new version to SVN. I have finished the support for tiled > maps, now you can add a new map type on maps.txt for tiled maps. The format > is: > TILE filename scale size_X size_Y > where > - filename is a text file with the same format of maps.txt that contains the > images/maps description for each tile (they don't need to be ordered) > - scale is the scale factor > - size_X is the number of columns > - size_Y is the number of rows, that is the map is a rectangular array of > size_X*size_Y tiles > > I have also corrected the problems with gpsd 2.xx using a diferent approach > (a gpsd callback function) and it seems to work know although it needs a > more intensive testing. > > I have tested this on a Zaurus C3100 and a C760 (Cacko and original Sharp > ROMs), latest gpsd 2.34 and a sirf 3 CF card. > I have also updated my page http://gtm.tel.uva.es/ztep/maps/dmap.htm so it > support tiled maps. > > Please, test this version in other machines and other ROMs (OpenZaurus - > opie, for example). > If someone is interested in testing, but he doesn't want to compile it, I > can post ipks for gpsd and qpegps for Sharp based ROMs. > > My plans are to test this version during the next week and if no major bugs > are found make a public release (v0.9.3). Then, when we receive feedback > from general public use release revision versions (0.9.3.x) if needed. > > My next task will be to add route support (I'm going to contact Nicolas > GUILLAUME, that has developed a version with routes in order to make an > unified version) and perhaps a whole GUI change. > > Best Regards, > ztep > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Qpegps-devel mailing list > Qpe...@li... > https://lists.sourceforge.net/lists/listinfo/qpegps-devel > > |
From: ztep <zt...@gm...> - 2006-12-31 11:09:52
|
Merry Christmas!! I have uploaded a new version to SVN. I have finished the support for tiled maps, now you can add a new map type on maps.txt for tiled maps. The format is: TILE filename scale size_X size_Y where - filename is a text file with the same format of maps.txt that contains the images/maps description for each tile (they don't need to be ordered) - scale is the scale factor - size_X is the number of columns - size_Y is the number of rows, that is the map is a rectangular array of size_X*size_Y tiles I have also corrected the problems with gpsd 2.xx using a diferent approach (a gpsd callback function) and it seems to work know although it needs a more intensive testing. I have tested this on a Zaurus C3100 and a C760 (Cacko and original Sharp ROMs), latest gpsd 2.34 and a sirf 3 CF card. I have also updated my page http://gtm.tel.uva.es/ztep/maps/dmap.htm so it support tiled maps. Please, test this version in other machines and other ROMs (OpenZaurus - opie, for example). If someone is interested in testing, but he doesn't want to compile it, I can post ipks for gpsd and qpegps for Sharp based ROMs. My plans are to test this version during the next week and if no major bugs are found make a public release (v0.9.3). Then, when we receive feedback from general public use release revision versions (0.9.3.x) if needed. My next task will be to add route support (I'm going to contact Nicolas GUILLAUME, that has developed a version with routes in order to make an unified version) and perhaps a whole GUI change. Best Regards, ztep |
From: Graham <gr...@4o...> - 2006-12-01 23:00:00
|
Hi, Yes, I am still here, though I have been tied up with a number of other=20 things for the past couple of weeks or so. I will grab a copy of your gpsd updates and take a look myself and see=20 if I can help. I have also been thinking about profiles vs. nested map folders and I=20 think both can be useful. My nested folders addition doesn't affect=20 anything if the feature isn't used, so it shouldn't add confusion or=20 unnecessary complication if it is included. I will also look at how it=20 fits with the updates which are in progress. I don't guarantee to work fast, especially as I am doing quite a bit of=20 travelling at the moment! Graham ztep wrote: > From: "Graham" <gr...@4o...> > =20 >> My main thoughts were to update to latest gpsd, using the lib interfac= e, >> hopefully making the communication to gpsd cleaner. It also offloads t= he >> work of interpreting the gps info to the expert library so qpegps can = get >> on with displaying it. There seems to be a number of extra pieces of >> information gpsd will report (such as position errors) so I am thinkin= g >> about finding ways to display those without cluttering the interface. >> =20 > > Hi Graham, > > Are you still interested in develop the compatibility with the latest g= psd? > > I have uploaded to svn a version of my trial with gpsd 2.xx as a branch= of > the head version I uploaded past weekend. > > This version works quite well if I poll gpsd with a timer every 500 ms,= but > my goal is to use a QSocketNotifier to know when ther is new data form = gpsd. > I have got problems with this because the activated() signal is never > called. Things that I notice: > - The socket descriptor given by gpsd is allwais 0. I know that this is= a > valid value, but is it not reserved for standar input? > - When I start qpegps from the shell (./qpegps) in order to see the mes= sages > from qDegug sentences, it starts to receive QSocketNotifier notificatio= ns > after I press return on the shell (qpegps is the running process of tha= r > shell, that is I don't run in in background with &). After pressing ret= urn, > all works ok. > > If you (or someone else) can use my code as starting point it is on: > https://svn.sourceforge.net/svnroot/qpegps/branches/gpsd2xx/qpegps > > This code is based on trunk revision 237 that I uploaded to svn on nove= mber > 18, I'm going to continue adding track animation support from v0.9.2.3.= 3 to > this version, but as long as you only need to work on client.h/cpp and > gpsstatus.h/cpp files, we can work together. > > Regrards, > ztep > > > =09 > ______________________________________________=20 > LLama Gratis a cualquier PC del Mundo.=20 > Llamadas a fijos y m=F3viles desde 1 c=E9ntimo por minuto.=20 > http://es.voice.yahoo.com > > =20 |
From: ztep <juj...@ya...> - 2006-11-23 08:39:28
|
From: "Graham" <gr...@4o...> > My main thoughts were to update to latest gpsd, using the lib interface, > hopefully making the communication to gpsd cleaner. It also offloads the > work of interpreting the gps info to the expert library so qpegps can get > on with displaying it. There seems to be a number of extra pieces of > information gpsd will report (such as position errors) so I am thinking > about finding ways to display those without cluttering the interface. Hi Graham, Are you still interested in develop the compatibility with the latest gpsd? I have uploaded to svn a version of my trial with gpsd 2.xx as a branch of the head version I uploaded past weekend. This version works quite well if I poll gpsd with a timer every 500 ms, but my goal is to use a QSocketNotifier to know when ther is new data form gpsd. I have got problems with this because the activated() signal is never called. Things that I notice: - The socket descriptor given by gpsd is allwais 0. I know that this is a valid value, but is it not reserved for standar input? - When I start qpegps from the shell (./qpegps) in order to see the messages from qDegug sentences, it starts to receive QSocketNotifier notifications after I press return on the shell (qpegps is the running process of thar shell, that is I don't run in in background with &). After pressing return, all works ok. If you (or someone else) can use my code as starting point it is on: https://svn.sourceforge.net/svnroot/qpegps/branches/gpsd2xx/qpegps This code is based on trunk revision 237 that I uploaded to svn on november 18, I'm going to continue adding track animation support from v0.9.2.3.3 to this version, but as long as you only need to work on client.h/cpp and gpsstatus.h/cpp files, we can work together. Regrards, ztep ______________________________________________ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com |
From: Juan J. V. <ju...@te...> - 2006-11-17 20:59:40
|
Hi, I have almost done the import of my current changes to version 0.9.2.3.1_modified. I'll have to solve a few issues that I have found during my tests but I think that along this weekend I will upload my changes to the SVN server, so you can test it while I work on the other task I have pending: 1.- To Integrate changes of versions 0.9.2.3.2 and 0.9.2.3.3 (mainly track animation) on the current version 2.- To add support for tiled maps (my initial and delayed task) I difn't know if the changes introduced in the maps/track drawing improves the speed, so I have done some measures about the duration of the createMap function. I used my C3200 and qpegps verison 0.9.2.3.3 vs my current work version (0.9.3 pre ?). With version 0.9.2.3.3, this function takes about 90 ms (mean of 3000 executions) without drawing places or track. The problem is that selecting that draw a track of 50 points (very short track) the duration of that funcion increase to about 118 ms. I haven't node measures with larger tracks but when I tied to use a large track to simulate a route some time ago, the screen takes several (3-5) seconds to update. With my current version the mean duration of createMap is about 40 ms (55% less than previous version!!), but the most important is that this time is not increased showing tracks. The inconvenient is that when there is a change in the map to show the duration of createMap is higher. The total time depends on the map size (about 350 ms for a 1000x1000 map) and increase when tracks or places ar shown. But the good news is that this occurs only each several minutes (again it frecuency depends of the map size, scale and your travel speed). Regards, Ztep |
From: jujovilla <juj...@ya...> - 2006-11-13 11:18:13
|
Yann Dirson wrote: > On Sun, Nov 12, 2006 at 10:04:03AM +0100, ztep wrote: >> I remit you to an old answer from Ralf: "Top from CVS, you can >> browse it here http://qpegps.cvs.sourceforge.net/qpegps/qpegps/ >> but fetch it logged in as a developer." >> When you access via web interface, you get an old code but whe I >> used the command line >> (cvs -z3 >> -d:ext:dev...@qp...:/cvsroot/qpegps co >> -P modulename) I've got the 9.3 version with profiles and almost all >> changes from version 9.2.3.3. > > Well, I just checked, and here is what I found out: > > - I was indeed still using anonymous access to cvs, but after > switching my workspace to ssh "cvs update" did not find anything new > - in both cases cvsps reports the latest revision as tagged > v0-9-2-3-1_modified (commit dated 2005/08/23) > - that source version indeed says "qpeGPS 0.9.3" in qpegps.cpp > > The 0.9.2.3.x series by Lance/ashikase were released as such: > > Aug 9 2005 qpegps_0.9.2.3.1_src.zip > Dec 13 2005 qpegps_0.9.2.3.2_src.zip > Feb 2 2006 qpegps_0.9.2.3.3_src.zip > > Moreover, Lance said, in those last mails of qpegps-devel that are > visible in the sourceforge web archive, that he did not commit those > versions to cvs, since he was using a private svn repo for > developement. > > So it looks like switching back to cvs head would be discarding the > changes from the lasted releases made by Lance. > > Or did I miss something ? Your are right. After comparing the code I think that the code in cvs is v0-9-2-3-1_modified. As you said this version is called "qpeGPS 0.9.3" in qpegps.cpp as you said, and this is why I thought that it was the last version. So in v0.9.2.3.1 the code split in two branch: v0-9-2-3-1_modified on CVS and 0.9.2.3.3 by Lance/ashikase in the downloads. As far as I understand the changes incorporated in each versions are: v0-9-2-3-1_modified: - Some code cleanup - Adds config profiles. - Changes the settings screen layout - Changes how the start/resume/end scripts are called/managed and allows the user to change this scripts v0.9.2.3.2/0.9.2.3.3 - Show places/waypoints - Adds track animation - Some changes on ResumeCF (I don't have much knowledgment about the start/resume scripts, so I can said what changes are done and why) I think that before (or at the same time) other changes are done we must merge this versions (the main features added in each version are usefull). The question is how to do it. I have done my modifications (as told in a previous message) based on 0.9.2.3.3 and then ported/copied to v0-9-2-3-1_modified. If everybody agree to my changes proposal, I can add track animation (I already have added the show places feature to my code) and other changes form 0.9.2.3.3 to my current version so the main features of both branch will be there and we'll have a unified version. Regards, ztep ______________________________________________ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com |
From: ztep <juj...@ya...> - 2006-11-12 10:41:10
|
I have added v0.9.3 from CVS to SVN trunk. I think that that is the last version. I will add my current changes as a branch from this version. Regards, ztep ______________________________________________ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com |
From: ztep <juj...@ya...> - 2006-11-12 09:04:15
|
> On Sat, Nov 11, 2006 at 09:45:44PM +0100, Yann Dirson wrote: > >> I have finished porting my current changes (see my previous messages >> titled >> 'My current changes to qpegps' on qpegps-devel) from v0.9.2.3.3 ro v0.9.3 >> downloaded from cvs. I want to upload my changes so you can test it while >> I >> work on tiled maps. > > Hm, unless I missed something, CVS only contains a couple of changes > above v0.9.2.3.1. Where did you see the info you had a 0.9.3 ? I remit you to an old answer from Ralf: "Top from CVS, you can browse it here http://qpegps.cvs.sourceforge.net/qpegps/qpegps/ but fetch it logged in as a developer." When you access via web interface, you get an old code but whe I used the command line (cvs -z3 -d:ext:dev...@qp...:/cvsroot/qpegps co -P modulename) I've got the 9.3 version with profiles and almost all changes from version 9.2.3.3. >> P.D. I have detected and corrected a little bug parsing GPRMC nmea >> command. > > That reminds me the little patch I have - it may be the same as you :) > > > diff -ru qpegps_my/client.cpp qpegps-0.9.2.3.3+/client.cpp > --- qpegps_my/client.cpp 2006-02-02 17:04:37.000000000 +0100 > +++ qpegps-0.9.2.3.3+/client.cpp 2006-02-14 23:30:33.000000000 > +0100 > @@ -130,7 +130,7 @@ > widgetToReEnable = application->currentPage(); > > // start the timers > - readyToConnect("SPAVHBDX", 250); > + readyToConnect("SPAVHBDXR", 250); > > // mode enabled > d_opMode = MODE_SNIFF; This is not the bug I have found, as I told before I think that your are working with a old version. Regards, ztep ______________________________________________ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com |
From: ztep <juj...@ya...> - 2006-11-11 10:18:54
|
Hi, I have finished porting my current changes (see my previous messages titled 'My current changes to qpegps' on qpegps-devel) from v0.9.2.3.3 ro v0.9.3 downloaded from cvs. I want to upload my changes so you can test it while I work on tiled maps. The question is: How to upload my changes? There is no news about the SVN transaction, so I suppose that I should use CVS. But, will I upload to the main branch or create another one? what name should I use? Thanks. P.D. I have detected and corrected a little bug parsing GPRMC nmea command. ______________________________________________ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com |
From: Ralf H. <ral...@gm...> - 2006-11-05 20:50:42
|
Hi Yann, > > @Yann > > I'd prefer to migrate to SVN. > > Could you take over the coordination of doing this ? > > I can handle that. Thanks > Oh yes - I'm not yet a project member - my sf id is ydirson ;) done. Best Regards, Ralf |
From: Graham <gr...@4o...> - 2006-11-02 20:13:27
|
Ralf Haselmeier wrote: > Hi Graham, > > I'm sorry for the late reply. > Hi Ralf, and everybody else on the list. My name is Graham Jones - grahamj on oesf forums. >> I am looking a new >> versions of gpsd and some alterations to do with multiple ma >> p folders. >> > Please post your ideas and the "why, what and how" on > the qpegps-devel mailing list to avoid that several peaple are working > on the same issue. > My main thoughts were to update to latest gpsd, using the lib interface, hopefully making the communication to gpsd cleaner. It also offloads the work of interpreting the gps info to the expert library so qpegps can get on with displaying it. There seems to be a number of extra pieces of information gpsd will report (such as position errors) so I am thinking about finding ways to display those without cluttering the interface. > And it would be nice, if you post your interests and skills as well > (like knowledge about C++, Qt, map projections, map datum, NMEA, > languages (translations), docu, ....). > As for my skills and interest - I have been programming in C/C++ for a number of years now, and also use whatever other languages are useful/necessary at appropriate times. I have been using the Zaurus since the 5500 series and follow developments quite closely. I have done some programming in Qt, mostly for my own interests, but a few things which, when I have time to complete them, may see the light of day. I have to admit I don't have a huge amount of knowledge in map projections, datum or NMEA, but I am learning. A little while ago I produced a way to get Google maps into qpegps (simple use of Google maps and investigation to find the best parameters). I became interested in using a GPS unit to help me find my way around, naturally using the Zaurus, found and liked qpegps and would like to see it continue to evolve if possible. >> If you have any other comments about further development of >> qpegps I would be interested to hear. >> > "multiple map folders" why ? (can't it be done via the profiles ? Please check > the latest CVS code) > Interesting, I haven't seen a qpegps built/released with any of this code. Did any of the earlier releases include profiles? (and any of the other differences between CVS code and latest builds). I keep an eye on the project regularly but until recently hadn't started to build the code for myself. I was probably, perhaps foolishly, assuming the ipk's contained all the latest code, especially since the CVS source was last altered over a year ago. Since the most recent files distributed on SourceForge are from Jan when 0.9.2.3.3 was posted I didn't compare against CVS since that had not been updated for sometime before. I have checked it out and will see what the profiles do for me. My original thought behind multiple map folders was to be easily able to swap in and out different sets of maps without editing a central copy of maps.txt. Profiles may be a slightly different thing, though until I have built the code and tried it I don't know whether I can achieve the same effect. My observation on coming to this project with an interest in contributing is that the code in CVS does need to be unified with the "release" code so that there isn't confusion over the features in future. Anyway, I now need to look at the different versions of the source and decide how and where to continue. Graham |
From: ztep <juj...@ya...> - 2006-11-01 19:14:20
|
>> My next work is to transfer my previous work done over v0.9.2.3.3 to this >> version. Before, I want to tell you some of the chages I have >> incorporated >> in order to get your opinions/approval: >> 1 - Add MapSelector class as said on todo.txt: no comments (although I >> haven used QPixmapCache as explained later). > The idea of the QPixmapCache was based on the later possibility to use > the code for vector maps (drawing this maps takes some time, so there was > the idea of caching). Caching makes sense for tiles as well, but it can be > done a lot of different ways (e.g. manually select which tiles have to be > loaded from disc and which are kept inside the memory...). It's just > important that it is not necessary to load all tiles into the memory... Yes, I will plan to load only the maps involved in drawing the current map, that is the current position and an area around it. >> 2 - Improve map detection: Now to search which maps to include on >> actMapList it calls calcxy(...), that is a quite complex function, so it >> only search a few maps each iteration. I have improved this search adding >> as members of each map (on MapBase) the limits of the map (nort, south, >> west and east). This limits are calculated on the map constructor and >> checked on a funciton isInside(latitude, longitude) that is used in the >> map >> search and also to draw traks and places. Using this operation searching >> on >> a list of about 1000 maps it only takes 2-3 ms. > Calcxy was needed, if several maps are partially inside the display. > How do you handle this situation now ? (do you check which map has the > best > coverage if 2 maps are "inside" but do not cover the whole display; ok, > this > is less important if tiled maps are available). I use isInside position tu test if the current position is inside the map and then the map is loaded and added to actMapList. Then the map to show is selected just as before, using calcxy and coverge funcions. But this time you only have to iterate in actMapList that usually has only a few maps. Anyway when I implement tiled maps the main list of maps will be a lot sort and this problem will be less important, as you said. >> The idea is: you call MapDisp::createMap 4 times on a second, but you >> detect a map afer several seconds (or minutes depending on your speed and >> the maps zoom and dimensions), so I have tried to aligerate >> MapDisp::createMap at the cost of more memory usage and more time to load >> a >> map when it is detected to be on the cover area. > Another idea was to calculate the distance between the current position > and > the maps and then sort the maps by this distance: the closer a map is, the > more frequently it is checked. But if you found a fast and working way to > do > it, the better it is. The problem is that you must update the distance from the current position and then re-sort the map. I think that this can be as slow (or more) than the current implementation. > Please be careful about memory usage, because some PDAs have only 32M. > Which device are you using (Zaurus, Ipaq,...) ? I use a Zaurus C3200, but I also has tested it on a C760, both with cacko rom. ______________________________________________ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com |
From: Ralf H. <ral...@gm...> - 2006-11-01 18:05:42
|
Hi Juan, > First of all, two questions: > 1 - Someone has compiled/run this code? I have found at least 2 error > during the direct compilation (very easy to solve) It should be compiled (at least), but the last changes have been quite uncoordinated... sorry > 2 - In a first run after compilation, I have seen that the code to show the > Places/Waypoints are missing but exist on v0.9.2.3.3pre, is there any > reason or just an omission? The reason is, that not all developers used CVS ... sorry again But now it is mandatory (but it will probably change from cvs to svn). > My next work is to transfer my previous work done over v0.9.2.3.3 to this > version. Before, I want to tell you some of the chages I have incorporated > in order to get your opinions/approval: > 1 - Add MapSelector class as said on todo.txt: no comments (although I > haven used QPixmapCache as explained later). The idea of the QPixmapCache was based on the later possibility to use the code for vector maps (drawing this maps takes some time, so there was the idea of caching). Caching makes sense for tiles as well, but it can be done a lot of different ways (e.g. manually select which tiles have to be loaded from disc and which are kept inside the memory...). It's just important that it is not necessary to load all tiles into the memory... > 2 - Improve map detection: Now to search which maps to include on > actMapList it calls calcxy(...), that is a quite complex function, so it > only search a few maps each iteration. I have improved this search adding > as members of each map (on MapBase) the limits of the map (nort, south, > west and east). This limits are calculated on the map constructor and > checked on a funciton isInside(latitude, longitude) that is used in the map > search and also to draw traks and places. Using this operation searching on > a list of about 1000 maps it only takes 2-3 ms. Calcxy was needed, if several maps are partially inside the display. How do you handle this situation now ? (do you check which map has the best coverage if 2 maps are "inside" but do not cover the whole display; ok, this is less important if tiled maps are available). > 3 - Improve map drawing (specially when large tracks/places are shown). In > my code when a map is detected to cover the current position, the image is > loaded into a QPixmap and then MapDisp::createMap do a bitblt (throught a > MapSelector::DrawMap function)that is faster than the current > convertFromImage(...). > Also I pre-draw the track and the places/waypoints > into the Qpixmap during the map loading so MapDisp doesn't need to draw > them on each createMap iteration. yes, this parts needed some tuning > The idea is: you call MapDisp::createMap 4 times on a second, but you > detect a map afer several seconds (or minutes depending on your speed and > the maps zoom and dimensions), so I have tried to aligerate > MapDisp::createMap at the cost of more memory usage and more time to load a > map when it is detected to be on the cover area. Another idea was to calculate the distance between the current position and the maps and then sort the maps by this distance: the closer a map is, the more frequently it is checked. But if you found a fast and working way to do it, the better it is. Please be careful about memory usage, because some PDAs have only 32M. Which device are you using (Zaurus, Ipaq,...) ? > Please tell me your opinions about my work and if you think that I should > add this changes to the current qpegps. Great job, keep on going ! Thanks, Ralf |
From: ztep <juj...@ya...> - 2006-11-01 16:22:22
|
@ Ralf, >> So what is the latest version? what code sould I take to make my work? > Top from CVS, you can browse it here > http://qpegps.cvs.sourceforge.net/qpegps/qpegps/ > but fetch it logged in as a developer. I have downloaded that code (v0.9.3). I like this code: clean and ordered, not like the one included on v0.9.2.3.3pre. First of all, two questions: 1 - Someone has compiled/run this code? I have found at least 2 error during the direct compilation (very easy to solve) 2 - In a first run after compilation, I have seen that the code to show the Places/Waypoints are missing but exist on v0.9.2.3.3pre, is there any reason or just an omission? My next work is to transfer my previous work done over v0.9.2.3.3 to this version. Before, I want to tell you some of the chages I have incorporated in order to get your opinions/approval: 1 - Add MapSelector class as said on todo.txt: no comments (although I haven used QPixmapCache as explained later). 2 - Improve map detection: Now to search which maps to include on actMapList it calls calcxy(...), that is a quite complex function, so it only search a few maps each iteration. I have improved this search adding as members of each map (on MapBase) the limits of the map (nort, south, west and east). This limits are calculated on the map constructor and checked on a funciton isInside(latitude, longitude) that is used in the map search and also to draw traks and places. Using this operation searching on a list of about 1000 maps it only takes 2-3 ms. 3 - Improve map drawing (specially when large tracks/places are shown). In my code when a map is detected to cover the current position, the image is loaded into a QPixmap and then MapDisp::createMap do a bitblt (throught a MapSelector::DrawMap function)that is faster than the current convertFromImage(...). Also I pre-draw the track and the places/waypoints into the Qpixmap during the map loading so MapDisp doesn't need to draw them on each createMap iteration. The idea is: you call MapDisp::createMap 4 times on a second, but you detect a map afer several seconds (or minutes depending on your speed and the maps zoom and dimensions), so I have tried to aligerate MapDisp::createMap at the cost of more memory usage and more time to load a map when it is detected to be on the cover area. Please tell me your opinions about my work and if you think that I should add this changes to the current qpegps. In other mail I will explain my ideas for the tiled maps. Regards, ztep ______________________________________________ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com |
From: Ralf H. <ral...@gm...> - 2006-11-01 10:12:48
|
@ Juan, > example, in 0.9.2.3.3 code there is no profiles). http://qpegps.cvs.sourceforge.net/qpegps/qpegps/settings.cpp?revision=1.22&view=markup It allows to select (and create) several config files which can have their own gps, units and map path settings: the idea is to have an selection at startup, where you can choose between profiles => select if you need a street, marine or aviation setup .. ( it is also handy if you have several gps units with different settings or ...). > So what is the latest version? what code sould I take to make my work? Top from CVS, you can browse it here http://qpegps.cvs.sourceforge.net/qpegps/qpegps/ but fetch it logged in as a developer. @Yann I'd prefer to migrate to SVN. Could you take over the coordination of doing this ? Regards, Ralf |
From: Rev S. R. <si...@ru...> - 2006-10-31 23:09:18
|
Erm, I don't have an Ipaq anymore so can you drop me from the CC list? -- Rev Simon Rumble <si...@ru...> www.rumble.net The Tourist Engineer Geeks need vacations too. http://engineer.openguides.org/ "Why Windows NT Server 4.0 continues to exist in the enterprise would be a topic appropriate for an investigative report in the field of psychology or marketing, not an article on information technology." - John Kirch |
From: jujovilla <juj...@ya...> - 2006-10-31 23:06:07
|
Hello everyone, I'm Juan J. Villacorta (ztep on oesf forums). I've been working on qpegps during the last weeks. My first task is to add support for 'tiled' maps, that is maps compound of several images. Usualy a big area is covered with several images and at this moment qpegps switch from a image/map to another, but when your are near the border of a map qpegps show the area not covered by the map as black. The objetive is to avoid these black areas creating a virtual map compounds of several images. In other mail I will explain my ideas about how I'm planning to implement this task. I have started my work creating a MapSelector class as sugested in Todo.txt file. I have use as base code the files included on qpegps_0.9.2.3.3_src.zip downloaded from sf because I supossed that this file was the last version, but with these two mails I'm confused (for example, in 0.9.2.3.3 code there is no profiles). So what is the latest version? what code sould I take to make my work? Regards, Juan J. ----- Original Message ----- From: "Yann Dirson" <yd...@al...> To: "Ralf Haselmeier" <ral...@gm...> Cc: <qpe...@li...>; "Graham" <gra...@us...>; <juj...@ya...>; <Dmi...@gm...>; <ash...@us...>; <si...@ru...> Sent: Tuesday, October 31, 2006 11:03 PM Subject: Re: Developing Qpegps > Hi Ralf, > > On Tue, Oct 31, 2006 at 10:28:32PM +0100, Ralf Haselmeier wrote: >> I'm sorry for the late reply. >> >> > I understand you will be adding ztep to the users with CVS a >> > ccess - can I ask you to add me as well. >> Yes, everyone is welcome. >> (tomorrow I'll add you and Juan as developers) >> >> > I am looking a new >> > versions of gpsd and some alterations to do with multiple ma >> > p folders. >> Please post your ideas and the "why, what and how" on >> the qpegps-devel mailing list to avoid that several peaple are working >> on the same issue. >> And it would be nice, if you post your interests and skills as well >> (like knowledge about C++, Qt, map projections, map datum, NMEA, >> languages (translations), docu, ....). > > I was myself waiting for news on the svn migration front. I had noticed > some migration work in the new svn directory, but that looked like a > work in progress that was left unfinished. I was rather expecting > ahikase to import his own svn repository, including the code from latest > releases... Is there any status on this ? > > If the current svn-migration plan is stall, I'd like to help to complete > it, at least by properly moving cvs history, and importing the latest > releases which were not committed into cvs (and then shutting down the > cvs server). > > >> I CCed several people which wrote me mails about qpegps... >> Please respond to the mailing list if you are working on qpegps or if >> you are going to do.... > > There are many things I'd like to help to make better, including > improving usability in keyboard-less units (ipaq), waypoints, vector-map > support. Time is however a limiting factor :) > > Best regards, > -- > Yann. ______________________________________________ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com |
From: Ralf H. <ral...@gm...> - 2006-10-31 21:28:48
|
Hi Graham, I'm sorry for the late reply. > I understand you will be adding ztep to the users with CVS a > ccess - can I ask you to add me as well. Yes, everyone is welcome. (tomorrow I'll add you and Juan as developers) > I am looking a new > versions of gpsd and some alterations to do with multiple ma > p folders. Please post your ideas and the "why, what and how" on the qpegps-devel mailing list to avoid that several peaple are working on the same issue. And it would be nice, if you post your interests and skills as well (like knowledge about C++, Qt, map projections, map datum, NMEA, languages (translations), docu, ....). > If you have any other comments about further development of > qpegps I would be interested to hear. "multiple map folders" why ? (can't it be done via the profiles ? Please check the latest CVS code) > I am fairly new to the > code so I don't want to tread on too many toes while doing > this. Therefore we have the qpegps-devel mailing list ;-) I CCed several people which wrote me mails about qpegps... Please respond to the mailing list if you are working on qpegps or if you are going to do.... Best Regards, Ralf |
From: Yann D. <yd...@al...> - 2006-02-17 21:32:00
|
Before starting to submit my items, I did a quick review of the open Feature Requests. Some of them are already there, or are pretty near to, so can surely be closed rapidly. [ 887516 ] display map scale Done [ 793192 ] Selectable map scales Done [ 735070 ] Display Waypoint Markers Looks all done, or am I missing something ? [ 928489 ] Manual use without GPS Not much work left (see my comment) [ 817069 ] NAC Natural Area Coding System Do we want to bother with this ? Anyone knows how much widespread it is ? If it is really useful, it may be worth to be able to make a plugin of it, so people in places where any of their patents would not apply could use it, without making qpegps itself unusable in the US. Otherwise let's just close it :) -- Yann Dirson <yd...@al...> | Debian-related: <di...@de...> | Support Debian GNU/Linux: | Freedom, Power, Stability, Gratis http://ydirson.free.fr/ | Check <http://www.debian.org/> |
From: Yann D. <yd...@al...> - 2006-02-14 23:01:18
|
Lance wrote: >For the last several months, I have been working on and off with >updating qpeGPS, and have made quite a few changes. However, I have not >been keeping the SourceForge CVS repository up to date. The reason for >this is that I prefer Subversion, and have a local repository that I use >for my projects; keeping this repository in sync with CVS is a major >nuisance. Have you lookes at svk ? It is a layer above svn, which can fetch a branch from CVS (and other scm's) into your local svk repo, so that when you commit back into that branch, the commit goes through cvs. That should allow you to have the advantages of svn, while we would still be able to get the fresh code :) Speaking of fresh code, would it be possible to handle Bug#862816 ? Although I have not analyzed the issue, the provided fix works for me and at least for its author :) >According to the SourceForge site, Subversion service will be offered >starting sometime this month (currently it is in beta testing). When >this happens, would anyone be against switching the qpeGPS repository >from CVS to Subversion? I understand that I don't have much to say, since I have not contributed anything yet to this project, but since I indend to hack on it, I'll take the liberty to give my opinion. My feeling is that, although svn would definitely be a progress over cvs, it may not be the ideal solution: it's still a centralized system (you've become used to have local access to your svn history, don't you ;), it still does not record branch merges, and it's not available yet at sf, and we don't have a timeframe for this. OTOH, there is quite a choice of decentralized scm's out there, which offer the ability to work with the history (ie. doing commits, diffs, etc) while disconnected, allow to cleanup one's set of patches before committing them to the official repo, etc. I admit that I have not tested them all - my personnal favorite nowadays is git (+ cogito and stgit), most known for being used to host the linux kernel. Another comparable option (which I have not tested yet) is mercurial. I would advocate against arch/tla because of its complexity, and against monotone for its bad perfs. That said, I wouldn't be deadly offended if svn is elected, I would just sync it into a local git branch ;) Best regards, -- Yann Dirson <yd...@al...> | Debian-related: <di...@de...> | Support Debian GNU/Linux: | Freedom, Power, Stability, Gratis http://ydirson.free.fr/ | Check <http://www.debian.org/> |
From: Lance F. <ash...@us...> - 2006-02-06 01:41:22
|
Hello all, For the last several months, I have been working on and off with updating qpeGPS, and have made quite a few changes. However, I have not been keeping the SourceForge CVS repository up to date. The reason for this is that I prefer Subversion, and have a local repository that I use for my projects; keeping this repository in sync with CVS is a major nuisance. According to the SourceForge site, Subversion service will be offered starting sometime this month (currently it is in beta testing). When this happens, would anyone be against switching the qpeGPS repository from CVS to Subversion? Also, Ralf, as it appears that myself (and voblin) are the only ones currently working on qpeGPS, would it be possible for me to be made an administrator for the project? It would allow me easier management of the site without having to disturb you about every little detail. - Lance Fetters |
From: zze-CPH D. P e. RD-TECH-G. <pde...@rd...> - 2005-10-20 09:50:49
|
Hi all, =20 I try to compile qpegps 0.9.3.2.1 with qtopia phone edition. I have the following linking error: g++ -o qpegps .obj/debug-shared/gpsdata.o .obj/debug-shared/client.o .obj/debug-shared/mapdisp.o .obj/debug-shared/mapinfo.o .obj/debug-shared/maps.o .obj/debug-shared/settings.o .obj/debug-shared/fetchmap.o .obj/debug-shared/route.o .obj/debug-shared/dirview.o .obj/debug-shared/dirdialog.o .obj/debug-shared/gpsstatus.o .obj/debug-shared/track.o .obj/debug-shared/qpegps.o .obj/debug-shared/colordlg.o .obj/debug-shared/datum.o .obj/debug-shared/ellipse.o .obj/debug-shared/geocent.o .obj/debug-shared/moc_gpsdata.o .obj/debug-shared/moc_client.o .obj/debug-shared/moc_maps.o .obj/debug-shared/moc_mapdisp.o .obj/debug-shared/moc_mapinfo.o .obj/debug-shared/moc_settings.o .obj/debug-shared/moc_fetchmap.o .obj/debug-shared/moc_route.o .obj/debug-shared/moc_dirview.o .obj/debug-shared/moc_dirdialog.o .obj/debug-shared/moc_gpsstatus.o .obj/debug-shared/moc_track.o .obj/debug-shared/moc_qpegps.o .obj/debug-shared/moc_colordlg.o -lqpe -L/home/capgem33/cph/trolltech/qtopia/build/x86/lib -lqtopia -L/home/capgem33/cph/trolltech/qtopia/build/x86/lib -L/home/capgem33/cph/trolltech/qte/build/x86/lib -lqte /home/capgem33/cph/trolltech/qtopia/build/x86/lib/libqpe.so: undefined reference to `CategorySelectDialog::CategorySelectDialog(QString const&, QWidget*, char const*, bool)' /home/capgem33/cph/trolltech/qtopia/build/x86/lib/libqpe.so: undefined reference to `Global::mousePreferred()' /home/capgem33/cph/trolltech/qtopia/build/x86/lib/libqpe.so: undefined reference to `CategorySelectDialog::currentCategoryText() const' /home/capgem33/cph/trolltech/qtopia/build/x86/lib/libqpe.so: undefined reference to `CategorySelectDialog::setAllCategories(bool)' /home/capgem33/cph/trolltech/qtopia/build/x86/lib/libqpe.so: undefined reference to `CategorySelectDialog::currentCategory() const' collect2: ld returned 1 exit status make: *** [qpegps] Erreur 1 How can I solve it?=20 Many thanks. Philippe Dequier Tel : + 33 (0)4 76 76 24 92 |