search

cdfarrow / flextools

Python scripting utility for SIL FieldWorks Language Explorer (FLEx)
Other
16 stars 5 forks source link

Reduce number of "Run" buttons? #19

Closed bbryson closed 1 year ago

bbryson commented 2 years ago

It's not clear to me why we need both "Run" and "Run (Modify)". Couldn't FlexTools just figure out which one is needed? I'm inclined to tell users "just use "Run (Modify) all the time", but then it is annoying to have messages come up when they run it on a module that doesn't need it: "Changes disabled". That also feels unnecessary. It would be nice to have only "Run" and "Run All" and let the "modify" part be figured out internally.

While we're at it, it would be nice to be able to select a subset of the modules showing (contiguous or not), and be able to "Run all selected". But I'm not asking for six buttons..... I wonder if "Run all" could automatically run all showing modules, and the "Run" button could have the effect of running the selected modules. Actually, this is issue #13.

cdfarrow commented 2 years ago

Thanks, Beth, for raising this. I created the Run/Run(Modify) model as a safeguard against making unwanted changes, with the Run option intended to be a "dry run" for a module that makes changes to the project. I'm reluctant to do away with the dry run option, as I think it is important for cases where people are potentially making significant changes to their data. However, in the case of FlexTrans, I can see how it seems like overkill with the two modes, plus the warning messages. FlexTrans is a well-polished system, and there probably isn't any need for end-users to ever do a dry run. So, based on your suggestions in this and related issues, I'm wondering if it would work to have a switchable option that simplified the operation like so:

rmlockwood commented 2 years ago

I think this looks good. I think we could disable the Are you sure message box. Maybe this is configurable?

bbryson commented 2 years ago

This looks promising to me.

My impression is that I can't run modules in "Run" mode currently, if they are marked as modifying the database. So I guess I never actually got the benefit of the "dry run" mode.

Anyway, I think this is a good idea.

cdfarrow commented 2 years ago

My impression is that I can't run modules in "Run" mode currently, if they are marked as modifying the database. So I guess I never actually got the benefit of the "dry run" mode.

I don't think any of Ron's modules support doing a dry run, so you've been seeing a strict Modifies/Doesn't-Modify dichotomy. For development and testing of modues, and for processes that might be a bit 'scary' to run on your project (e.g. Merge duplicates) it is helpful to be able to see what it will do before actually committing to it. (It is like Preview in Bulk Edit.)

Actually, maybe the term 'preview' would be clearer than 'dry run'...

bbryson commented 2 years ago

Yes, I really like your proposal, especially with the "switchable option", so you can still have "dry run" or "preview" for other kinds of modules. If you did all that you propose here, that would help immensely!

cdfarrow commented 1 year ago

Fixed for 2.2.2. Added FTConfig.simplifiedRunOps, which when set to True, hides the Dry-run/Preview buttons and menu items. All Run actions behave as "Run Modify". This option operates independent of FTConfig.warnOnModify.

Also, if warnOnModify is True, then it now doesn't display the Are you sure? dialog if the module or modules don't make changes.