What's the reason for using emoji as icons? You shouldn't really do that. Is this code generated by AI? If so, we have a rule for that: - [EGO Review Guidelines: AI](https://gjs.guide/extensions/review-guidelines/review-guidelines.html#extensions-must-not-be-ai-generated) - [Extensions Best Practices Guidelines](https://gjs.guide/extensions/review-guidelines/best-practices.html#submissions-require-maintainership)

> What's the reason for using emoji as icons? You shouldn't really do that. > Is this code generated by AI? If so, we have a rule for that: Ah sorry I'd like to apologize I did not know about the common UI rules in the GNOME ecosystem. The emoji comes from a 1:1 port of a similar plugin I maintained for the macOS ecosystem. It is called SwiftBar and I maintain it for a couple of years now: https://mpm.run/bar-plugin/#screenshots . If you don't like that and is against UI rules I will remove them them, no worries. The original reason I used them in my SwiftBar/Xbar version is to make the status visually easier to read and more compact to not take too much space in the menu bar. As for AI no, this extensions was not vibe coded, but still used LLMs as glorified auto-complete for some of the comments and docs. But I understand your frustration as I myself am a core developer of a popular Python package and is overwhelmed by the AI slop we receive (see: https://github.com/pallets/click/discussions/3361#discussioncomment-17984508 ).If the extensions looks a bit complex it is because it shadow the structure of that SwiftBar plugin I maintain. So maybe some structure can be a bit too over-engineered, but it covers 10 years of bugs and issues I had to handle. Any way thanks for the fast reply! I'm ready to make any changes necessary! :)

It's okay if the emojis are intentional but still better to use icons instead. 1. `this._destroyed` is a bad practice. Please remove that: [Extension Best Practices Guidelines: Lifecycle and Destruction State](https://gjs.guide/extensions/review-guidelines/best-practices.html#lifecycle-and-destruction-state) 2. Please use `connectObject()` and `disconnectObject()` so it is easier to track for cleanup (`extension.js` process only). 3. Timeout should be removed on cancel (line 144 `mpm.js`): [EGO Review Guidelines: Timeout](https://gjs.guide/extensions/review-guidelines/review-guidelines.html#remove-main-loop-sources) The way the function receives `cancellable` as null is actually hard to review in future updates. If you don't pass a cancellable, that timeout won't be removed on disable if it is delayed. Then it will be executed on lock, which is a security risk. For timeouts, devs usually store the timeout ids in an array, then call a cleanup function on disable that loops through the ids and removes them. 4. Since you're also developing the mpm CLI, I highly recommend removing all subprocess calls and switching to D-Bus. That would make this extension a true frontend. The extension and mpm CLI can to communicate over D-Bus: [D-Bus Guide](https://gjs.guide/guides/gio/dbus.html) If you need any help with your extension you can ask us on: - [GNOME Extensions Matrix Channel](https://matrix.to/#/#extensions:gnome.org) - IRC Bridge: irc://irc.gimpnet.org/shell-extensions

Thanks for the review! I overlooked some details but these are quite mechanical so will be easy to fix. For point #4, this is an original direction I never considered. I need to look at this in details as I am not familiar at all with the DBus architecture. Let me work on that and I'll be back in a couple of weeks with a solid update, as I will need to synchronize both mpm release and its gnome extension.

Hi JustPerfection, Thanks for the detailed review and your patience. I took the time to release a new major version of `mpm`, so the update took longer than I anticipated. Also found a couple of issues I reported upstream to the wider Gnome project. About your points: 1. **Icons instead of emoji**: all emoji are gone from the UI. Every state and every menu entry now uses icons from the native themes. 2. **`this._destroyed` removed**: the lifecycle now follows the guidelines. 3. **`connectObject()` / `disconnectObject()`**: adopted everywhere in `extension.js`. 4. **Timeouts and cancellables**: this one was a bit tricky. `runCommand()` now *requires* a `Gio.Cancellable` parameter. 5. **D-Bus**: not yet. I studied your suggestion seriously and you are right that it would make the extension a true frontend. But that would mean making `mpm` a long-running service with a proper API. Maybe spawn up a full server from an `mpm dbus-server` command or something. I'm not against it but I need way more time and exploration. Maybe you can point me to a good reference or example of a similar project? But first I want to focus on making the extension usable and reliable day to day. If anything is still wrong, I'm ready to fix it, now that my 8.0.0 is out I can iterate faster.