GUI: Add "Copy in Python" button to module dialogs

[polucifier]

Description

This PR introduces a new button "Copy in Python" to all GRASS module dialogs in the wxGUI. While the existing "Copy" button provides the shell command, this new feature generates valid Python syntax using the grass.script library (standard gs alias).

The goal is to streamline the workflow for users transitioning from the GUI to Python scripting and to provide a quick way to prototype scripts directly from the interface.

Key Features & Improvements

• Standard Syntax: Generates code using the gs.run_command() pattern, which is the most common entry point for GRASS scripting.
• Robust String Escaping: Uses Python's built-in repr() function for parameter values. This ensures that Windows file paths (backslashes), quotes, and special characters are handled correctly without breaking the Python string literal.
• Python Keyword Handling: Automatically detects reserved Python keywords (e.g., from, in, global). If a module parameter name conflicts with a keyword, the PR uses dictionary unpacking (e.g., **{'from': 'map'}) to ensure the generated code is syntactically valid.
• Global Parameters: Correctly translates GUI-specific items like --overwrite, --verbose, and --quiet into their Pythonic True/False arguments.
• Future-Proofing: Includes a fallback for any other double-dash flags (--) that might be introduced by third-party addons.

Example Output

For a module like v.distance -p -s --overwrite from=durham@user1 to=bridges@PERMANENT upload=dist format=plain, the button generates:

gs.run_command('v.distance', flags='ps', overwrite=True, to='bridges@PERMANENT', upload='dist', format='plain', **{'from': 'durham@user1'})

Testing

• Manually tested with various modules
• Verified that the generated strings are valid and executable when pasted into the GRASS Python console.

[echoix]

I like the concept, similar to what there is in QGIS, even if I never used these in qgis (only the copy as json and paste it again later on to rehave the same parameters set)

[polucifier]

I like the concept, similar to what there is in QGIS, even if I never used these in qgis (only the copy as json and paste it again later on to rehave the same parameters set)

Thanks for the feedback, @echoix! I really like the QGIS workflow you mentioned. I'm going to convert this PR to a Draft for now while I refine the UI.

My plan is to replace the standalone 'Copy in Python' button with a MenuButton (dropdown) integrated into the main 'Copy' button. It will include:

• Copy as Shell command (default)
• Copy as Python script (using the logic from this PR)
• Copy as JSON (as you suggested)

To complete the loop, I will also try to implement a 'Paste' button that can take a JSON string and automatically populate the dialog fields. I'll push these updates later this evening.

[ninsbl]

Nice. Did you consider returning tools API syntax?

[polucifier]

Nice. Did you consider returning tools API syntax?

Hi @ninsbl, thank you very much for the suggestion! That's a great idea. Since I'm already reworking the 'Copy' button into a dropdown menu, I'll add two more options to it: 'Copy as Python (Tools API)' and 'Copy as Python (PyGRASS)'.

Combined with the Script API and JSON options, this should cover all the major Python workflows in GRASS. I'll push the updates later.

[polucifier]

I have implemented a new Split Copy Button and a Paste functionality for the module dialogs. This update provides users with multiple export formats and a way to quickly restore or share tool parameters via JSON.

New UI layout with the Split Copy button and the Paste button:

The dropdown menu offers various formats, including the new Tools API and JSON:

The following examples demonstrate the generated output. Note that Python reserved keywords (e.g., from) are correctly handled using dictionary unpacking to ensure valid, executable code:
Shell command:

v.distance -p -s --overwrite from=durham@user1 to=bridges@PERMANENT upload=dist format=plain

Python (Script API):

gs.run_command('v.distance', flags='ps', overwrite=True, to='bridges@PERMANENT', upload='dist', format='plain', **{'from': 'durham@user1'})

Python (Tools API):

Tools().v_distance(flags='ps', overwrite=True, to='bridges@PERMANENT', upload='dist', format='plain', **{'from': 'durham@user1'})

Python (PyGRASS):

Module('v.distance', flags='ps', overwrite=True, to='bridges@PERMANENT', upload='dist', format='plain', **{'from': 'durham@user1'})

JSON format:

{
    "module": "v.distance",
    "params": {
        "flags": "ps",
        "overwrite": "True",
        "from": "durham@user1",
        "to": "bridges@PERMANENT",
        "upload": "dist",
        "format": "plain"
    }
}

Demonstration of the Paste functionality, which populates dialog fields and updates the command preview in real-time:
Paste.webm

[ninsbl]

Cool. Just for clarification: does Copy as JSON copy json equivalent to --json, or just the the parameters that were set with their values?

[ninsbl]

I now see the JSON structure in your comment above... Background for my question has been: #6697

[pesekon2]

The functionality is great. I really like it. I would have some doubts about the usability of the Paste button but if @echoix says he can imagine users for that, why not having it.

I tested the functionality and it seems fine to me. However, I don't see the arrow on the dropout of the Copy button. It seems seems to me more like a wxPython issue than being connected to the PR. What is your version of wx? Mine is 4.2.3.

[polucifier]

Hi @pesekon2, thanks for the feedback! I'm glad the functionality works well for you.

Regarding the missing arrow: I have the same version of wxPython (4.2.3). You were right—the issue was most likely caused by the previous implementation using a text-based character for the chevron, which renders inconsistently across different platforms and themes.

To resolve this and ensure a professional look on all systems, I have completely overhauled the visual implementation in the latest commit.

Technical Improvements:

• Custom Drawing with wx.GCDC: Instead of relying on text characters, I am now drawing the chevron icon manually. Using wx.GCDC ensures smooth, anti-aliased lines.
• True Transparency: I switched to wx.Bitmap.FromRGBA to create a 32-bit bitmap. This eliminates "black box" artifacts and ensures the button background blends perfectly with the native UI.
• Automatic Theme Support: The icon color is now dynamically pulled from wx.SYS_COLOUR_BTNTEXT, making it fully compatible with both light and dark system themes.
• Pixel-Perfect Alignment: I've implemented platform-specific vertical offsets (including a -2px shift for Windows). The chevron is now mathematically and visually aligned with the baseline of the "Copy" text (specifically the letter 'C'), verified down to the pixel in GIMP.

Here is the final result across different environments:

Linux - Dark Theme

Linux - Light Theme

Windows - Light Theme

[pesekon2]

Why is this needed? Is it not handled by the common garbage collector?

[polucifier]

As far as I know, while Python's GC eventually handles memory, wxPython objects are wrappers around C++ structures that often require deterministic destruction.

In this case, wx.GCDC holds a reference to the underlying wx.MemoryDC. According to the wx.MemoryDC documentation:

"Note that the memory DC must be deleted (or the bitmap selected out of it) before a bitmap can be reselected into another memory DC."

My understanding is that by explicitly calling del gc, we force the C++ destructor of the graphics context to run immediately, flushing the drawing and releasing the lock on the MemoryDC. Relying on the non-deterministic Python GC can sometimes lead to "DC is busy" errors or incomplete rendering because the GCDC might still be "alive" when mdc.SelectObject(wx.NullBitmap) is called.

[pesekon2]

Thanks. Now I got the arrow there. A weird and ugly one but something is there.

But I got two more points:

1. The button Paste is not really self-exlanatory. Could the text be clearer? Like Paste JSON settings? I don't want to make the bar too long (but cannot come with anything shorter now) but currently, the user doesn't really know what type should s/he paste there. Which comes to:
2. It should raise a clearer error message if something wrong is pasted. Currently, I just get Paste Error: Expecting value: line 1 column 1 (char 0).

[pesekon2]

What is the meaning of this change? I thought it might be the performance (although the difference would be absolutely unnoticeable) but I tried testing these two and the tuple version is slightly faster.

[echoix]

Are these accepted values for the flags?

[polucifier]

The change from a tuple to a set literal was suggested by Ruff:
#7237 (review)

While the performance difference is negligible for a collection of this size, I assume that Ruff enforces this as a best practice for membership tests (in) to maintain consistent style across the codebase.

Regarding the specific values: these are all standard ways different GRASS modules and XML descriptions represent a "true" or "active" state for flags.