-
Notifications
You must be signed in to change notification settings - Fork 128
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create default IGC extensions list and provide option to include more, or exclude defaults #1061
Comments
Alternatives:
|
The usability of checkboxes , a string a bool options, is strong.
Representing string options in a GUI and error checking them isn't awesome.
We know that, like most other software, the defaults are very much what
people use. Be mindful if we really need a dozen knobs to turn here at all.
The kinds of people willing to manage/script 200 character invocations are
also the ones willing to rebuild with a constexpt bool FooFlag flipped.
…On Mon, Apr 10, 2023, 7:47 AM tsteven4 ***@***.***> wrote:
Alternatives:
1. have a string option with a default that can be overridden. The
default could be "fxa;oat;siu;" or whatever. On the command line you can
override it with whatever you want. It takes more characters to specify a
long list but it is clear what you get.
2. do something like the clang-tidy checks option
<https://clang.llvm.org/extra/clang-tidy/#id2>. In this case globs
only makes sense as everything.
igc,ext=-
*;fxa;oat;siu disable all defaults, add fxa, oat, siu
igc,ext=-enl;-oat,siu use defaults except no enl, no oat, and add siu.
igc,ext=* use everything
As clang tidy does you will need to have a way to display what
extensions are actually used. Perhaps this can/is done with -D1.
—
Reply to this email directly, view it on GitHub
<#1061 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCSD36JTQJESTFDWWDOUNDXAP6MLANCNFSM6AAAAAAWYMW45I>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
Oh wow, neat!, I had no idea! I'll have to play with various ways of representing the options in the code and see how it translates to the GUI. I was dreading the thought of writing anything like this. Can you point me to an example?
Already do, see Edit: does this automatic mapping occur at run or compile time? (can't check right now) |
Options set up in igc.h in variable igc_args. gpx_args in gpx.h is a more complete example including some options with ARGTYPE_BOOL. At run time the GUI queries the CLI and basically recovers all the *_args format variable data. It builds the format option screens from that data. The filter option screens are different, they are hand crafted. By 1. I meant a single string option shown below. Note I specified a set of default extensions. You get these if you don't enter the option on the command line at all. If you specify ext=abc;def then that overrides the default, you just get abc and def. |
This diff theoretically implements individual boolean options for each extension and provides a set of defaults. It's getting to be a lot of QHashes and QMaps, though; perhaps a And, that's a bit of pointing and and dereferencing that's a wee bit over my head, although I'm pretty sure I understand it. It would definitely need a second look specifically at the It also doesn't apply those defaults when the IGC options dialog is opened in the GUI, although it does very smartly construct the list of arguments with a bit of pointing and clicking. That feature is quite impressive. |
If we've settled on a ARGTYPE_BOOL option for every supported IGC extension read on. I think your trying too hard. Help is available with -h. option echoing is available with -D 1. If you want -D to print both true and false use "0" defaults as well as "1" in igc_args. So if we can skip the specific debug info you added then IgcFormat::get_extension_ingestion_2 can be simplified and we don't need the description map (which may have wanted to be hashes (https://doc.qt.io/qt-6/containers.html) or just a series of if statements. It looks like further processing of the ARGTYPE_BOOL options is not implemented yet, and that may involve ext_option_map. Perhaps I led you down this path with "As clang tidy does you will need to have a way to display what extensions are actually used. Perhaps this can/is done with -D1.". If so, sorry. Between -h and -D 1 and the manual isn't enough feedback available? If you want to expand on the help for an option in the manual then create xmldoc/formats/options/igc-ENL.xml for the ENL option, etc. There is a subtle difference between a ARGTYPE_BOOL of nullptr and "0" or "1". WIth a nullptr default you can just test the argval for nullptr (or just an implicit conversion to bool). With "0" you need to dereference argval and compare to '0'. An example when a default is used from nukedata.cc is " if (*nukertes != '0')". This same code will dereference a nullptr if there isn't a default and the option isn't supplied or is false. The GUI runs the CLI, the CLI doesn't know if it is being run by a user or the GUI. The GUI only passes BOOL options that aren't the default value. `$ ./bld/gpsbabel -h igc
tsteven4@PEDALDAMNIT:~/work/pf2$ ./bld/gpsbabel -D 2 -i igc -f reference/track/92HV66G1.igc |
You're reading a bit too much into the debug output in get_extension_ingestion_2(), I think. What's there right now is just there to make sure everything works right; as you noticed, those options aren't actually used yet. I just needed a quick and dirty way to make sure I was referencing and dereferencing everything correctly. Basically, just ignore everything in that function for now, it's just a stub to test and demonstrate usage I like the general idea of ext_description_map because it's one place to change those strings if they get used in multiple places, which I assume will make translations and documentation easier. A QMap may well not be the best way to implement it, though. I like the bool options because as Robert noted, this presents checkboxes in the GUI which are far easier to interact with and test than constructing a string. |
This is my next crack at this. It needs quite a bit of cleanup still, but it generally works. With these options, we can eliminate special cases for extensions like TRT and SIU and simply default them to off. Then the end user can decide if they really want to turn that knob on. There's got to be a better way to do this, though:
|
This is my initial idea. I'm sure there's a better way to implement it, but the general idea is that by specifying
-i igc,include=siu
or-i igc,exclude="enl;oat"
, for example, a user can work with a default set of included extensions, and modify that list as they see fit.Diff here
The text was updated successfully, but these errors were encountered: