search

mate-desktop / mozo

Menu editor for MATE using the freedesktop.org menu specification
http://www.mate-desktop.org
GNU Lesser General Public License v2.1
28 stars 12 forks source link

Applications are removed from Preferred Applications after their properties have been accessed in mozo #89

Open mesov opened 2 months ago

mesov commented 2 months ago

Expected behaviour

Using mozo does not interfere with the Preferred Application tool.

Actual behaviour

Upon selecting an application in mozo and clicking on the "Properties" button, then closing the Launcher Properties window, if that application was listed in Preferred Application, the corresponding entry is removed from the list.

Steps to reproduce the behaviour

  1. start Main Menu (run mozo).
  2. select an application that is listed in Preferred Applications (e.g. LibreOffice Writer).
  3. click on "Properties" to display the Launcher Properties window.
  4. close the Launcher Properties window and close mozo.
  5. start Preferred Applications (run mate-default-applications-properties) and observe that LibreOffice Writer is not listed any more in Office > Word Processor.

Workaround

Removing the .desktop file that has been created in ~/.local/share/applications or running update-desktop-database ~/.local/share/applications/ restores the application entry in Preferred Applications. This only solves the problem retroactively, and only for that application. The same issue will happen with other applications.

Related issue reports

https://github.com/mate-desktop/mate-control-center/issues/150#issuecomment-266231423 https://github.com/mate-desktop/mozo/issues/17 https://github.com/mate-desktop/mozo/issues/18 https://github.com/mate-desktop/mozo/issues/77

MATE general version

1.26.0

Package version

mozo 1.26.1-1

Linux Distribution

Ubuntu 22.04 Trisquel 11.0

Link to bugreport of your Distribution (requirement)

https://bugs.launchpad.net/ubuntu/+source/mate-desktop-environment/+bug/1914847 https://gitlab.trisquel.org/trisquel/package-helpers/-/issues/183

lukefromdc commented 2 months ago

This looks like Mozo and mate-control-center's preferred applications capplet are both writing to the same filenames in ~/.local/share/applications/ and neither is reading pre-existing files and preserving their content in the rewritten files. In other words, Mozo is stepping on mate-control-center and the converse is probably also the case

mesov commented 2 months ago

Mozo is creating a copy of the .desktop file in ~/.local/share/applications/ overriding the original /usr/share/applications/ file without updating mimeinfo.cache. Adding a hook in mozo that would run update-desktop-database ~/.local/share/applications/ after writing in ~/.local/share/applications/ would probably remove the glitch.

update-desktop-database only looks into system directories if no option is specified. See https://gitlab.gnome.org/GNOME/glib/-/issues/1610#note_390274.

lukefromdc commented 2 months ago

A team member familiar with Mozo's code will have to get on that one, but at least we now have a starting point. If someone outside the team codes this up, I can test it and see if it works, but I am not now able to code this without a lot or research and effort

mesov commented 1 month ago

not now able to code this without a lot or research and effort

Same here. I will simply be avoiding accessing launcher properties from mozo until it can be fixed.