Re: [Gpsbabel-code] GUI idea (was Re: gpsbabel lowranceusr.c bug report+fix)

[Robert L. <rob...@gp...>]

We replaced guibabel years ago with the Qt code.  That's where any
improvements should be focused.
On Jul 18, 2013 10:09 AM, "Jerzy Tarasiuk" <Jer...@fu...>
wrote:

> Hello, thanks for your reply.
>
> I found a file "guibabel" distributed with the gpsbabel
> - it is quite antiquated (2006-03-21) and does not handle
> most of gpsbabel formats, so I have idea to make better.
>
> My idea is that GUI gets info what the gpsbabel can do
> from the program and allows to specify all possible
> formats, filters and options - without need to change
> the GUI script when new ones are added.
>
> I planned using gdb to extract format and filter lists
> and their options, but it is slow (takes minutes to get
> all data) and I still do not have full information what
> I need to get - how to "decode" internal formats, which
> are defined in the file "internal_styles.c".
>
> Options -^3 and -%1 (about the first I found info in
> the "gpsbabel-code" archive, second I found looking into
> main.c) give the info quickly, although something is
> missed in it: option type flags, there are e.g. ranges
> of mutually exclusive options, seems -^3 does not show
> that some options form such a range.
>
> Questions: Is currently someone working on GUI in Tcl/Tk?
> What such a GUI should provide to be useful? I assume
> the most important is ability to find the program usage
> info without need to look into documentation, and apply
> it in a convenient way (without typing names); with near
> 200 formats, a way to search within them is a must.
>
> With kind regards, Jerzy Tarasiuk
>
>
> Some clarifications about my previous mail:
>
> > On Fri, Jul 5, 2013 at 12:06 PM, Jerzy Tarasiuk
> > <Jer...@fu...>wrote:
> >> Symptoms: I used an Lowrance USR (from Silva Atlas GPS) file
> >> and converted it to GPX (-i lowranceusr -o gpx), then back
> >> to Lowrance USR (-i gpx -o lowranceusr), and again to GPX.
> >> The second GPX file was significantly different from the first
> >> - many (probably all, I did not verify it) coordinates were
> >> shifted, they became slightly smaller than they were.
> > Where "significantly" presumably means lower than the precision of your
> > GPS, right?
>
> Right. The "significance" meant amount of differences,
> not severity of them - the shift was around 0.6 m.
>
> > This is C++; we always have a well-defined
> > lround().<http://www.cplusplus.com/reference/cmath/lround/>
>
> The program can be compiled as C program, and the compiler
> needs -std=c99 option to recognize then lround(). I don't
> know if there is anyone using older compiler w/o the option.
>
> >> With the fix, the only difference becomes line 8, containing
> >> time where the file was written. I have an idea to fix this,
> > I don't know what line 8 you're speaking of, but this change rather
> > predictably blew up the test suite.  I've regenerated your reference
> > files and have committed the whole change in r4401.
>
> I meant line 8 of GPX file - it contains time when the file
> was written, so obviously if can be different; setting the
> GPSBABEL_FREEZE_TIME stores beginning of Unix time there,
> so the time is the same each time - useful for testing.
>
> > The timestamp in GPX is working as intended.  If we were a simple
> > 1:1 converter, some cleverness in preserving source file creation might
> > be in order, but since we can merge and filter files, we regard the
> output
>
> OK. Maybe it would be useful to timestamp the output file
> according to data in it - to newest time found in the data
> - maybe as a filter option? Especially for those who have
> many data files collected, so they could use "ls -lrt"...
>
> I understand the file may be newly created work, I just
> did not use gpsbabel in other way than format change.
>
>
>