Fix spawn_async crash, load user env for commands, and add "Customize" button

[furik30]

Description:

This PR fixes a crash in modern GNOME versions, improves the execution of user commands, and adds quick, customizable access to the extension settings.

1. Fix: spawn_async warns

Background: I was trying to understand why my custom command wasn't working. Eventually, I dug into the logs and saw: JS WARNING: [resource:///org/gnome/shell/ui/environment.js 375]: Too many arguments to function Shell.util_spawn_async: expected 4, got 5

Problem: In modern GNOME versions (for example, I'm on Fedora 41/42), GLib.spawn_async throws a "Too many arguments" error because the user_data argument is no longer accepted in the bindings.

Solution: Updated the _cmdAsyncButton.js file — now only valid arguments are passed, which eliminates the crash (I removed 2 args because the JS warning kept whining in the logs).

Warning

If critical I was acting at random, fixing for the sake of fixing; do not accept _cmdAsyncButton.js into production without prior checks.

2. Improvement: Loading user environment

Continuation: since the command still didn't work after the fix, I started digging into my own code.

Problem: User commands were executed in a non-interactive shell, which meant user aliases and scripts in ~/.local/bin (added via .bashrc) were not found by the system.

Solution: The customButton.js file has been updated to use execution via /bin/bash -l -c. The login shell flag (-l) ensures that the full user environment and the $PATH variable are loaded before the command is executed.

3. New feature: "Configure this menu" button

Added an optional button at the very bottom of the menu for quick access to this extension's settings.

• Toggle: You can enable or disable this button in the Settings (enabled by default).

• Schema: Added the show-settings key to the gschema.xml file.

• Interface: The button perfectly matches the style of the other menu buttons.

4. Localization

Updated translations for the new button and settings toggle, as well as screenshots for all supported languages (I didn't think it would be so tedious):

• ✅ English (Template)
• ✅ Russian (ru)
• ✅ French (fr)
• ✅ Italian (it)
• ✅ Portuguese (Brazil) (pt_BR)
• ✅ Chinese (Simplified) (zh_CN)

Note

Regarding localization files In reality, I did this using a py-script from Gemini, and all the new strings are at the bottom rather than being properly structured. Honestly, I'm too lazy to fix it, and I can't really vouch for the translation quality, though everything seems correct at first glance.

Oh, and I also fixed the README for the RU locale, it was written by some tiny Grok model, so there were some errors there, I tried to get as close to the original as possible.

Summary

In the end, the reason for my problems was that I had misconfigured the alias for my awful command, so even bash "command" wouldn't execute 🤣 but since I was already halfway through, I didn't want to waste the work already done.

Tested on GNOME 48 (Wayland)

[furik30]

@axelitama Oh yeah, I forgot to remind you that the "customization button" is already enabled btw
It might annoy people, you can turn it off, although I think it's useful, I first downloaded several plugins and then didn't understand how to configure them until I got on Reddit

[axelitama]

Thank you so much for all the great work!!

1. Perfect! I already fixed the "Too many arguments" error for another button in the past, but I didn't realized it was causing the problem also there. I also have GNOME 48, but it works fine in my system...

2. Good idea to load user env for custom commands. Another strategy could also be to pass only the command directly to the button making the user responsible to put /bin/bash in their command if they need it... What do you think?

3. Perfect! I just moved the button at the very end (after GNOME log-out button, but I will not retake all the screenshots lol) and added the 'options' unicode symbol in the displayed text.

4. I can't check all the languages niether, maybe I'll put a warning in the english README to please report incorrect translations

Let me know what you think!

[axelitama]

Then regarding the button position I was thinking of something like this as a future update: [issue #9]

[furik30]

Thanks for the feedback and for fixing up the locales!

Regarding the User Environment (Bash strategy)

You make a valid point. Hardcoding /bin/bash creates a hidden behavior that might block users who want to run Python scripts or binaries directly.

Thought for the future: Maybe we could add a simple "Run in Shell" checkbox in the Custom Command editor? If checked, it would wrap the command in bash -l -c. But for this PR, I agree it's better to keep the core logic clean and simple.

I will revert the logic in customButton.js to pass the command directly, if that needed.

Screenshots & Testing (Tip)

Since you mentioned the pain of logging out to test languages/UI 😅, here is the trick I used. You can run a nested GNOME Shell instance with a specific locale and resolution inside a window without logging out:

# Example: Italian locale, 1920x1080 window
LC_ALL=it_IT.UTF-8 MUTTER_DEBUG_DUMMY_MODE_SPECS=1920x1080 dbus-run-session -- gnome-shell --nested --wayland

(idk, LLM says me "that will work", and that works well)

You can then open the extension menu inside that window and take screenshots.

Regarding Localization

I noticed you cleaned up the translation files in my branch — thank you!

Out of curiosity, what tool do you use to manage .po files? I used a custom Python script to append strings, which was a bit "hacky," so I'd love to know the proper workflow for future contributions.
Thanks for help!

[furik30]

Oh, by the way, regarding the "Customize" button — you read my mind! I added the functionality, but I wasn't sure about the best placement, so I'm glad you tweaked it!

If you decide that a "Run in Shell" checkbox is the way to go for Custom Commands, I can try to implement and test it right here within the framework of this PR. Just let me know!

As for the button positioning/reordering [issue #9] — honestly, I don't even have any thoughts on that yet; it looks like quite a lot of work to implement a full drag-and-drop system, and I think there might also be some compatibility issues...

[axelitama]

Thought for the future: Maybe we could add a simple "Run in Shell" checkbox in the Custom Command editor? If checked, it would wrap the command in bash -l -c. But for this PR, I agree it's better to keep the core logic clean and simple.

That is a good idea and it makes absolutely sense for the future.

I will revert the logic in customButton.js to pass the command directly, if that needed.

For now maybe it is better to keep it wrapped in bash to ensure compatibility with the previous version.

Since you mentioned the pain of logging out to test languages/UI 😅, here is the trick I used. You can run a nested GNOME Shell instance with a specific locale and resolution inside a window without logging out:

Thank you so much for the tip, it works great and it will for sure make everything much faster!

Out of curiosity, what tool do you use to manage .po files? I used a custom Python script to append strings, which was a bit "hacky," so I'd love to know the proper workflow for future contributions. Thanks for help!

I did a make script that scan all js files to find new strings and update .po files. You can lunch it with make sync-locales (it needs xgettext and msgmerge to work). It keeps the strings already translated and add the new ones with empty translation. It also reorder them and avoid repetitions. For the new translations I think it is ok to use an llm at first, then I will put a warning in all readmes to please report or fix incorrect translations

[axelitama]

If you decide that a "Run in Shell" checkbox is the way to go for Custom Commands, I can try to implement and test it right here within the framework of this PR. Just let me know!

I absolutely think it is the way to go! Right now I do not have much free time, so if you want to implement it, go for it!

As for the button positioning/reordering [issue #9] — honestly, I don't even have any thoughts on that yet; it looks like quite a lot of work to implement a full drag-and-drop system, and I think there might also be some compatibility issues...

You may be right... I’ll check whether there’s already something available that can handle this in the preferences window. I will never implement it from scratch...