Re: [Gpsbabel-code] How about a (non-G)UI?

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

Ron Parker wrote:

> To that end, would there be any objection to my hijacking the argc==1
> case in main() and sending it off to a semi-interactive shell-like
> environment that holds their hand through the process of building a
> pipeline while still requiring them to know how to type, specify a

Over the weekend, I was considering just making the 'argc=1' case just
call guibabelfront.  (To eliminate mutual recursion, we should be sure
it's impossible to build an "argc=1" case from guibabelfront.  Yeah,
it's tacky and incestuous.

Notice it's not the Mac or *nix guys that are having the problem, so I
wouldn't even bother to try to figure out whether we should use the Tk
version or not.

> flag in the option-type stuff I added last week: we need to know
> whether an option is input or output, and whether it's required on

This is going to be snobbish, but we you honestly think that any of
our funky options are really that useful to the crowd that gets scared
when they have to type stuff?  The "I want this file to be converted to
that file type" crowd doesn't need the options and the folks that do
the froggy stuff are building funky command lines and sticking them in
macros or batch files or scripts or whatever anyway.

> output."  Since filters don't do input and output, the existing flag
> would keep its existing "required" role for filters.

Filters are a good example of something that I've considerd "out of
reach" for the typeless crowd.  Arbitrary conversion of routes and
tracks are on that list, too, but it turns out that conversion between
Magellan SD and Magellan Mapsend is a common use since Mapsend won't do
it and boht cases share the same limitations.

A "real" gui that did try to take advantage of this stuff really would
have to understand the options availble (and thus always be behind) and
not try to divine every possible option via an inquiry.

RJL