Skip to content

Conversation

@NotSirius-A
Copy link
Contributor

Hello, this PR fixes some issues (see bottom) related to cutting/pasting/deleting items in the cinnamon-menu-editor.

Sorry for the very long description, but it took me a long time to (sort of) understand this application, so I think I should provide a detailed description so that more people can easier understand/review these changes.

Changelog and explanation

Commit 4b0f5cb:

This commit fixes bad UX when copying items. Whenever user clicks on the "Copy" button no visual changes occur, despite the fact that the application places the item into a buffer. This might lead the user to think that copying "doesn't work". Pasting will only activate when user selects a category from the left menu.

To fix this I've added one line to the on_edit_copy_activate() function. This line simulates user reopening the category that is currently open -> the one where copying occured. This will cause the currently selected items to deselect and will activate the "Paste" button, which will provide necessary UI feedback to the user. This issue was mention in the #9293 (comment)

Commit dbc7fe6

This commit fixes two cutting/pasting bugs. First of all the current "cut" functionality is not really a cut. It just copies an item and immediately removes it, which is not how cutting should work. Items shouldn't be deleted until they're pasted somewhere. This commit fixes this through the introduction of a new variable self.item_to_cut, which indicates that cutting is (not) in progress.

This commit also fixed issues with duplicate cutting, by that I mean the incorrect behavior that occurs whenever cutting non-user-made items, which causes the same item to appear where its supposed to be pasted (correct), but also in its original category (incorrect duplicate). This is only worsened by fact that deleting either of these duplicated causes both to be deleted. This is caused by the fact that the pasted item is XML <Include>ed into the target category, but it is also displayed in the original one, because of the Categories .desktop property.

My fix dbc7fe6#diff-c98f55b82ed859a581afcbd203640e9e8dd29811a0cfd3db9d133c99f1becbdcR257 to this works by altering how items are pasted. Instead of just pasting the item I think it's also required to alter its Categories attribute in the .desktop file. My code basically just overrides the default Categories (which cause the duplication), with the category name of where the item was pasted into.

For example, the calculator app is by default in Categories=GNOME;GTK;Utility;Calculator;, after the paste into "Graphics" my code would transform .desktop of the pasted item to Categories=Graphics;.

Unfortunately recent changes from a692d52#diff-04e819d30a3cd74ec4ed5faf25823f7121c8043dc21dbe9ecfa9231b2e7e19e7R54 are unexpectedly causing more issues here, because this also makes the editor add an additional (unneeded) localized property for ex. Categories[en_US]=Graphics;. While this is incorrect behavior I don't think it would cause any issues for now. I figured I should leave this alone and let maintainers make a decision, because I'm sure you know better than me.

Issues which this PR is based on

In my opinion this PR closes

@fredcw
Copy link
Contributor

fredcw commented Jan 10, 2026

I looked at the code a few years ago, and to me it looked half finished. It also seems unnecessarily complicated in the way it makes changes to the user's desktop-directory XML files rather than just the user's .desktop files. I think it would be better to get rid of it altogether and replace it with something else. Mozo (MATE) would be a lot of work to convert to cinnamon and also looks unnecessarily complicated, although the UI is better. I think the way to go is to fork MenuLibre and slim down the UI a bit so it isn't too technical.

Edit: On second thoughts, the issue is the cut/copy/paste buttons and how they work. We could allow the user to select which categories to show an app in in the properties dialog and this would change only Categories= string in the .desktop file instead of adding stuff to ~.config/menus. That way a lot of the complexity in the menu-editor code could be removed. The ability to add nested categories is also not needed since all the menu applets ignore this anyway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants