Re: [Viking-devel] Import file via gpsbabel

2011-09-29 Thread Guilhem Bonnefille
2011/9/8 Guilhem Bonnefille guilhem.bonnefi...@gmail.com:
 2011/9/8 Robert Norris rw_nor...@hotmail.com:

 A. It is slightly annoying one may specify the 'file type' twice (especially 
 when it's a choice of over 150 kinds!)

 i.e. One goes into file selection dialog, chooses a filter, then picks a 
 file.
 But then need to set the file type to be used in our Import File dialog.
 Or vice versa - set a file type but then is not used as the filter when 
 actually picking a file.

 Obviously files can be called anything and have any file type - which we 
 have to tell gpsbabel.

 It might be better to order the Import File dialog like this:
 1. File Type
 2. Filename Selection
 3. Track/Route/Waypoint options

 Then on choosing the file type, this can auto set the default used for the 
 file selection.

 One matter: two lists are not simmetrical as some file types does not
 have file extension.

 IMHO, if we have to change part of this, we have to implement
 something that preset the file type when a file is selected.

Humh... not so easy to implement. I prefer to publish this feature as
is (not enought spare time for this topic).

 B. Be wary of the track/route/waypoint options not doing what you think they 
 should do!

 I thought if I deselected the waypoint or track options and opened a gpx or 
 kml file then I would *not* get that type of information.
 This does not seem to be the way GPSBabel works - especially on file 
 conversions - or the behaviour is dependent on the file format used.

 I think track/route/waypoint options mainly apply to the serial data formats 
 not the file conversions.

 Some options in order of difficulty:
 1. Add GUI visible statement that they only work on some file formats (but 
 which ones???)
 2. Remove these track/route/waypoint options
 3. Perform automatic post processing ourselves to remove the kinds of data 
 the user doesn't want.

 Yes, it seems that -t/r/w options do not already work the same way for
 all file type.

 For example, I use these options to convert magellan files to gpx and
 gpx to magellan format. I know I need these options to route
 gpsbabel to the right format to produce, as magellan does not mix
 track, route and waypoint in the same file.

It seems that the simpler (and so better) solution is to remove these
options. The user can remove data later, on TRW layer.

So, no need for these GUI option nor command line option.

 C. Importing files this way don't get stored into the recently opened file 
 list. [It would be difficult to open them as nothing is stored about what 
 type it is - it is possible an auto guess based on filename extension could 
 work for some but not all files.].

 I'm OK with not going into the recently opened list.

 Yes, it is currently an import, not a file openning.

Note that we can certainly register a complex GtkRecentData and
supporting a new command line option to import a file with a given
GPSBabel format.


-- 
Guilhem BONNEFILLE
-=- JID: gu...@im.apinc.org MSN: guilhem_bonnefi...@hotmail.com
-=- mailto:guilhem.bonnefi...@gmail.com
-=- http://nathguil.free.fr/

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
Viking-devel mailing list
Viking-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viking-devel
Viking home page: http://viking.sf.net/


Re: [Viking-devel] Import file via gpsbabel

2011-09-08 Thread Guilhem Bonnefille
Hi,

Thanks for all these comments.

2011/9/8 Robert Norris rw_nor...@hotmail.com:

 Some observations for further discussion and unfortunately larger (re)work.

When coding this feature, I also realized all the limits you spotted
about current implementation. But I imagined that it is significant
work to implement all this. So, I decided to create a simple solution,
perhaps not trivial for user, but simple.

Please, found some more details in-text.

 A. It is slightly annoying one may specify the 'file type' twice (especially 
 when it's a choice of over 150 kinds!)

 i.e. One goes into file selection dialog, chooses a filter, then picks a file.
 But then need to set the file type to be used in our Import File dialog.
 Or vice versa - set a file type but then is not used as the filter when 
 actually picking a file.

 Obviously files can be called anything and have any file type - which we have 
 to tell gpsbabel.

 It might be better to order the Import File dialog like this:
 1. File Type
 2. Filename Selection
 3. Track/Route/Waypoint options

 Then on choosing the file type, this can auto set the default used for the 
 file selection.

One matter: two lists are not simmetrical as some file types does not
have file extension.

IMHO, if we have to change part of this, we have to implement
something that preset the file type when a file is selected.

 B. Be wary of the track/route/waypoint options not doing what you think they 
 should do!

 I thought if I deselected the waypoint or track options and opened a gpx or 
 kml file then I would *not* get that type of information.
 This does not seem to be the way GPSBabel works - especially on file 
 conversions - or the behaviour is dependent on the file format used.

 I think track/route/waypoint options mainly apply to the serial data formats 
 not the file conversions.

 Some options in order of difficulty:
 1. Add GUI visible statement that they only work on some file formats (but 
 which ones???)
 2. Remove these track/route/waypoint options
 3. Perform automatic post processing ourselves to remove the kinds of data 
 the user doesn't want.

Yes, it seems that -t/r/w options do not already work the same way for
all file type.

For example, I use these options to convert magellan files to gpx and
gpx to magellan format. I know I need these options to route
gpsbabel to the right format to produce, as magellan does not mix
track, route and waypoint in the same file.

I have to check more.


But note we know which feature is supported by which file type. The
choice we have to decide is the scenario:
- do we filter the available options following the selected file type
- do we filter the available file types following the selected options

I'm not sure what an user will prefer.

 C. Importing files this way don't get stored into the recently opened file 
 list. [It would be difficult to open them as nothing is stored about what 
 type it is - it is possible an auto guess based on filename extension could 
 work for some but not all files.].

 I'm OK with not going into the recently opened list.

Yes, it is currently an import, not a file openning.

 D. Slight aside, but whilst in the area - we should probably use the '-p ' 
 option to override users gpsbabel .ini defaults.

 See http://www.gpsbabel.org/htmldoc-1.4.2/inifile.html

Thanks for this.

 
 Date: Wed, 7 Sep 2011 22:05:41 +0200
 From: guilhem.bonnefi...@gmail.com
 To: viking-devel@lists.sourceforge.net
 Subject: [Viking-devel] Import file via gpsbabel

 Hi,

 As many of you already know, viking uses gpsbabel for many features.
 Most of them concern format conversions. But, currently, only some
 formats are offered via viking. I not really know why viking does not
 support all formats supported by gpsbabel. And recently, I discovered
 that gpsbabel is able to list all the formats and options it knows.

 I made many changes on viking. Before merging them on viking's master
 branch, Any comments are welcome:
 http://repo.or.cz/w/viking/guyou.git/shortlog/refs/heads/import-via-gpsbabel


-- 
Guilhem BONNEFILLE
-=- JID: gu...@im.apinc.org MSN: guilhem_bonnefi...@hotmail.com
-=- mailto:guilhem.bonnefi...@gmail.com
-=- http://nathguil.free.fr/

--
Doing More with Less: The Next Generation Virtual Desktop 
What are the key obstacles that have prevented many mid-market businesses
from deploying virtual desktops?   How do next-generation virtual desktops
provide companies an easier-to-deploy, easier-to-manage and more affordable
virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
___
Viking-devel mailing list
Viking-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viking-devel
Viking home page: http://viking.sf.net/


[Viking-devel] Import file via gpsbabel

2011-09-07 Thread Guilhem Bonnefille
Hi,

As many of you already know, viking uses gpsbabel for many features.
Most of them concern format conversions. But, currently, only some
formats are offered via viking. I not really know why viking does not
support all formats supported by gpsbabel. And recently, I discovered
that gpsbabel is able to list all the formats and options it knows.

I made many changes on viking. Before merging them on viking's master
branch, Any comments are welcome:
http://repo.or.cz/w/viking/guyou.git/shortlog/refs/heads/import-via-gpsbabel

-- 
Guilhem BONNEFILLE
-=- JID: gu...@im.apinc.org MSN: guilhem_bonnefi...@hotmail.com
-=- mailto:guilhem.bonnefi...@gmail.com
-=- http://nathguil.free.fr/

--
Using storage to extend the benefits of virtualization and iSCSI
Virtualization increases hardware utilization and delivers a new level of
agility. Learn what those decisions are and how to modernize your storage 
and backup environments for virtualization.
http://www.accelacomm.com/jaw/sfnl/114/51434361/
___
Viking-devel mailing list
Viking-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viking-devel
Viking home page: http://viking.sf.net/


Re: [Viking-devel] Import file via gpsbabel

2011-09-07 Thread Robert Norris

I will try to take a look.   One concern is that gpsbabel seems inclined
to require QT for the command-line version!   But it seems likely better
to put up with that bloat than to do anything else.


It shouldn't do, depending on how it's packaged.

For Debian it's split into gpsbabel + gpsbabelfe programs.

Dependencies for the command line program:
$ldd /usr/bin/gpsbabel
    linux-vdso.so.1 =  (0x7b9ff000)
    libusb-0.1.so.4 = /lib/libusb-0.1.so.4 (0x7fa869dd5000)
    libz.so.1 = /usr/lib/libz.so.1 (0x7fa869bbe000)
    libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7fa86993b000)
    libexpat.so.1 = /usr/lib/libexpat.so.1 (0x7fa869713000)
    libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7fa86938f000)
    /lib64/ld-linux-x86-64.so.2 (0x7fa86a002000)

Whereas the gpsbabelfe has all the GUI dependencies (can't be bothered to list 
them - as there are 61 of them).
  
--
Using storage to extend the benefits of virtualization and iSCSI
Virtualization increases hardware utilization and delivers a new level of
agility. Learn what those decisions are and how to modernize your storage 
and backup environments for virtualization.
http://www.accelacomm.com/jaw/sfnl/114/51434361/
___
Viking-devel mailing list
Viking-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viking-devel
Viking home page: http://viking.sf.net/


Re: [Viking-devel] Import file via gpsbabel

2011-09-07 Thread Greg Troxel

Robert Norris rw_nor...@hotmail.com writes:

I will try to take a look.   One concern is that gpsbabel seems inclined
to require QT for the command-line version!   But it seems likely better
to put up with that bloat than to do anything else.


 It shouldn't do, depending on how it's packaged.

 For Debian it's split into gpsbabel + gpsbabelfe programs.

 Dependencies for the command line program:
 $ldd /usr/bin/gpsbabel
     linux-vdso.so.1 =  (0x7b9ff000)
     libusb-0.1.so.4 = /lib/libusb-0.1.so.4 (0x7fa869dd5000)
     libz.so.1 = /usr/lib/libz.so.1 (0x7fa869bbe000)
     libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7fa86993b000)
     libexpat.so.1 = /usr/lib/libexpat.so.1 (0x7fa869713000)
     libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7fa86938f000)
     /lib64/ld-linux-x86-64.so.2 (0x7fa86a002000)

 Whereas the gpsbabelfe has all the GUI dependencies (can't be bothered
 to list them - as there are 61 of them).

Sorry, I realize that's how it is now (similar on NetBSD).

On the gpsbabel list, Robert said that he was going to use QT for basic
data structures and thus cause the command-line version to depend on QT.


pgpL1cDegcmuO.pgp
Description: PGP signature
--
Using storage to extend the benefits of virtualization and iSCSI
Virtualization increases hardware utilization and delivers a new level of
agility. Learn what those decisions are and how to modernize your storage 
and backup environments for virtualization.
http://www.accelacomm.com/jaw/sfnl/114/51434361/___
Viking-devel mailing list
Viking-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viking-devel
Viking home page: http://viking.sf.net/

Re: [Viking-devel] Import file via gpsbabel

2011-09-07 Thread Robert Norris


Some observations for further discussion and unfortunately larger (re)work.

A. It is slightly annoying one may specify the 'file type' twice (especially 
when it's a choice of over 150 kinds!)

i.e. One goes into file selection dialog, chooses a filter, then picks a file.
But then need to set the file type to be used in our Import File dialog.
Or vice versa - set a file type but then is not used as the filter when 
actually picking a file.

Obviously files can be called anything and have any file type - which we have 
to tell gpsbabel.

It might be better to order the Import File dialog like this:
1. File Type
2. Filename Selection
3. Track/Route/Waypoint options

Then on choosing the file type, this can auto set the default used for the file 
selection.


B. Be wary of the track/route/waypoint options not doing what you think they 
should do!

I thought if I deselected the waypoint or track options and opened a gpx or kml 
file then I would *not* get that type of information.
This does not seem to be the way GPSBabel works - especially on file 
conversions - or the behaviour is dependent on the file format used.

I think track/route/waypoint options mainly apply to the serial data formats 
not the file conversions.

Some options in order of difficulty:
1. Add GUI visible statement that they only work on some file formats (but 
which ones???)
2. Remove these track/route/waypoint options
3. Perform automatic post processing ourselves to remove the kinds of data the 
user doesn't want.


C. Importing files this way don't get stored into the recently opened file 
list. [It would be difficult to open them as nothing is stored about what type 
it is - it is possible an auto guess based on filename extension could work for 
some but not all files.].

I'm OK with not going into the recently opened list.

D. Slight aside, but whilst in the area - we should probably use the '-p ' 
option to override users gpsbabel .ini defaults.

See http://www.gpsbabel.org/htmldoc-1.4.2/inifile.html







Be Seeing You - Rob.
If at first you don't succeed,
then skydiving isn't for you.



 Date: Wed, 7 Sep 2011 22:05:41 +0200
 From: guilhem.bonnefi...@gmail.com
 To: viking-devel@lists.sourceforge.net
 Subject: [Viking-devel] Import file via gpsbabel

 Hi,

 As many of you already know, viking uses gpsbabel for many features.
 Most of them concern format conversions. But, currently, only some
 formats are offered via viking. I not really know why viking does not
 support all formats supported by gpsbabel. And recently, I discovered
 that gpsbabel is able to list all the formats and options it knows.

 I made many changes on viking. Before merging them on viking's master
 branch, Any comments are welcome:
 http://repo.or.cz/w/viking/guyou.git/shortlog/refs/heads/import-via-gpsbabel

 --
 Guilhem BONNEFILLE
 -=- JID: gu...@im.apinc.org MSN: guilhem_bonnefi...@hotmail.com
 -=- mailto:guilhem.bonnefi...@gmail.com
 -=- http://nathguil.free.fr/

 --
 Using storage to extend the benefits of virtualization and iSCSI
 Virtualization increases hardware utilization and delivers a new level of
 agility. Learn what those decisions are and how to modernize your storage
 and backup environments for virtualization.
 http://www.accelacomm.com/jaw/sfnl/114/51434361/
 ___
 Viking-devel mailing list
 Viking-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/viking-devel
 Viking home page: http://viking.sf.net/
  
--
Using storage to extend the benefits of virtualization and iSCSI
Virtualization increases hardware utilization and delivers a new level of
agility. Learn what those decisions are and how to modernize your storage 
and backup environments for virtualization.
http://www.accelacomm.com/jaw/sfnl/114/51434361/
___
Viking-devel mailing list
Viking-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viking-devel
Viking home page: http://viking.sf.net/