lsp-plugins / lsp-plugins

Linux Studio Plugins Project
https://lsp-plug.in/
GNU Lesser General Public License v3.0
538 stars 46 forks source link

xdg .desktop files have invalid category #88

Closed eeickmeyer closed 4 years ago

eeickmeyer commented 4 years ago

0001-Fix-invalid-category.patch.txt lsp-plugins is not a valid xdg desktop category. As such, I have attached a patch that will fix it to the proper category of AudioVideo;Audio;. I hope this helps.

sadko4u commented 4 years ago

@eeickmeyer Hmm, I've already tried the similar patch. This will publish all program links directly into Audio group. I believe that's not a good idea since other applications will get lost in about 100+ program links.

In our case, all program links will be grouped into 'LSP Plugins' bundle: image

eeickmeyer commented 4 years ago

In that case, you might be able to make it X-lsp-plugins, but making your own category doesn't work with all operating systems. I can verify that, but making your own category that's not part of the freedesktop.org standard isn't allowed.

Right now, I have to do that massive patch in order to keep it standards-compliant in Ubuntu, which is not ideal. In Ubuntu Studio, we have a way of customizing the Audio Production menu that makes it standards-compliant while not overcluttering other menus. You can check out launchpad.net/ubuntustudio-menu if you want to see how we do that.

That said, I'm sure we can figure out a compromise that is both standards-compliant and allows you to customize the way you want. X-lsp-plugins might be the way to go, I just need to verify that.

sadko4u commented 4 years ago

@eeickmeyer Thanks. I'm not very familiar with XDG standard, so I'll mostly rely on your contribution and contribution from @dvzrv and @DNS777 . According to what I currently understand, @dvzrv has defined a lsp-plugins category in the lsp-plugins.menu file which is also installed by the build system. So probably this should work as expected.

dvzrv commented 4 years ago

From the spec:

Categories in which the entry should be shown in a menu (for possible values see the Desktop Menu Specification).

Looking at the menu spec there, it gets quite interesting... it seems as if they introduce the custom menu and then hardcode all the namespaced XDG desktop files into it: https://specifications.freedesktop.org/menu-spec/latest/apcs03.html

          <!DOCTYPE Menu PUBLIC "-//freedesktop//DTD Menu 1.0//EN"
          "http://www.freedesktop.org/standards/menu-spec/menu-1.0.dtd">
          <Menu>
            <Name>Applications</Name>
            <Menu>
              <Name>WebMirror</Name>
              <Directory>shinythings-webmirror.directory</Directory>
              <Include>
                <Filename>shinythings-webmirror.desktop</Filename>
                <Filename>shinythings-webmirror-admin.desktop</Filename>
              </Include>
            </Menu>

Closing, the desktop files should not mention a Categories entry but instead be pulled in by the custom menu item. I did not know that!

eeickmeyer commented 4 years ago

I was able to create a custom X-lsp-plugins category, but it did require a "main" category, so I gave it the main category of "Audio". With this patch, all .desktop files have Categories=Audio;X-lsp-plugins; as the category entry.

0001-Fix-invalid-category.patch.txt

While the custom lsp-plugins.menu may be existing, unfortunately, the .desktop files must still be XDG compliant. This latest (attached) patch keeps the .desktop files XDG compliant.

I'm not 100% certain, but @dvzrfv 's solution of eliminating the Categories= entry altogether might work as well.

sadko4u commented 4 years ago

@dvzrv Do I right understand that:

  1. I need to mention all *.desktop files in the 'lsp-plugins.menu' file?
  2. I am free to remove lsp-plugins from the 'Category' parameter now?
eeickmeyer commented 4 years ago

@sadko4u If you'd like, you're more than welcome to copy/paste the entries from what I did in ubuntustudio-menu:

https://git.launchpad.net/ubuntustudio-menu/tree/etc/xdg/menus/applications-merged/studio.menu

sadko4u commented 4 years ago

Please try patch committed into github-issue-88 branch: 3f0ff14d203f6e9ab826e35942f67f84fe0a1e22

Seems it's being properly working on my KDE installations (both menus): image

image

Tested on Virtual machine with 32-bit openSUSE Tumbleweed + KDE.

eeickmeyer commented 4 years ago

I can confirm that the patch does, indeed, work. In fact, it might be good enough for me to eliminate my individual file call-outs and simply add the entire .directory file inside our "Audio Production/Effects" submenu, essentially making it a submenu of that.

sadko4u commented 4 years ago

@dvzrv Can we consider that the latest changes have solved the issue?

dvzrv commented 4 years ago

Maybe it would be worth exploring, whether setting OnlyShowIn is an option, too. https://specifications.freedesktop.org/menu-spec/latest/ar01s03.html

Because, if I understand this correctly, listing several Categories will lead to the entries showing up in several menus, or does the explicit menu item lsp-plugins.menu prevent this now?

All in all, if this works, ship it!

sadko4u commented 4 years ago

@dvzrv Do I right understand that it should be:

OnlyShowIn:X-lsp-plugins;

?

sadko4u commented 4 years ago

Merged changes into devel branch: 8cf6793edaa191fb8b92be017d2335b5e83d07f8

dvzrv commented 4 years ago

On 2020-03-30 07:39:38 (-0700), Vladimir Sadovnikov wrote:

@dvzrv Do I right understand that it should be:

OnlyShowIn:X-lsp-plugins;

That's how I understand it.

sadko4u commented 4 years ago

At least I need to try it.

mikhailnov commented 4 years ago

OnlyShowIn is for DEs like KDE, GNOME,XFCE etc.

The OnlyShowIn field is a list of strings identifying the environments that should display a given menu item

Categories=Audio;X-lsp-plugins;

Why does not this make a ton of desktop files be shown in the "Audio" category? I think they will be shown there in some configurations but I am not very well familiar with this part of XDG.

eeickmeyer commented 4 years ago

Why does not this make a ton of desktop files be shown in the "Audio" category? I think they will be shown there in some configurations but I am not very well familiar with this part of XDG.

You are correct, this does make a ton of "Audio" menu entries. This is why I basically "blacklisted" them in the Ubuntu Studio menu. If you scroll through that link, you'll see the same files listed twice: once where they are blacklisted, and another time where they are wanted.

mikhailnov commented 4 years ago

Then it is not a solution for upstream, because most people do not have Ubuntu Studio menu installed, including the ones who install lsp-plugins package outside Ubuntu Studio. Maybe Categories=X-lsp-plugins; will be enough despite breaking full compilancy with XDG by not having a "main" category? What is the purpose of trying to be 100% compilant here?

eeickmeyer commented 4 years ago

What is the purpose of trying to be 100% compilant here?

This is why.

If not 100% compliant, the package is not allowed in Debian or Ubuntu. Remember, I report to people higher-up than myself.

Maybe Categories=X-lsp-plugins; will be enough despite breaking full compilancy with XDG by not having a "main" category

I tried that and got this warning.

mikhailnov commented 4 years ago

I think that an exception would be a good choice here. But, if it is not possible or if there is any other good reason to follow XDG specifications so strictly, commit https://github.com/sadko4u/lsp-plugins/commit/8cf6793edaa191fb8b92be017d2335b5e83d07f8 should be extended to not only <include>, but to also exclude plugins from the "Audio" category to make them invisible there. Maybe specifying "Audio" would really help to understand that these applications do something with audio, but I don't know why it may be needed.

eeickmeyer commented 4 years ago

It could be done by making a /etc/xdg/menu/applications-merged/lsp-plugins.menu which could blacklist the desktop entries from the Audio menu. Not trivial, but it can be done in a similar fashion to how I did it in ubuntustudio-menu.

sadko4u commented 4 years ago

@mikhailnov So, can you provide a proper solution?

P.S. It's strange that XDG specificaiton is so complicated for doing so simple things.

sadko4u commented 4 years ago

Added OnlyShowIn:X-lsp-plugins; for all desktop entries: a6ac014a92c88143956f453903ac15eb870794af

In KDE just works fine. Please check.

sadko4u commented 4 years ago

In Ubuntu I just get this: image

Don't know how correct it is for GNOME desktop but personally for me it is awful. Moreover, DE doesn't display icons.

mikhailnov commented 4 years ago

31.03.2020 12:06, Vladimir Sadovnikov пишет:

Added OnlyShowIn:X-lsp-plugins; for all desktop entries: a6ac014 https://github.com/sadko4u/lsp-plugins/commit/a6ac014a92c88143956f453903ac15eb870794af

In KDE just works fine. Please check.

As far as I understand, it is probably a KDE bug. Here "X-lsp-plugins" must be treated as a Desktop Environment name, so most DEs must just not show it at all. Am I incorrect?

mikhailnov commented 4 years ago

31.03.2020 10:53, Vladimir Sadovnikov пишет:

@mikhailnov https://github.com/mikhailnov So, can you provide a proper solution?

I struggle understanding XDG menu XML layouts, Erick has written above what should be done to avoid just removing Audio from categories.

Maybe they should be put inside "" tag as here: https://git.launchpad.net/ubuntustudio-menu/tree/etc/xdg/menus/applications-merged/studio.menu#n155 ?

mikhailnov commented 4 years ago

31.03.2020 12:16, Vladimir Sadovnikov пишет:

Don't know how correct it is for GNOME desktop but personally for me it is awful.

GNOME desktop does not sort applications by categories. "NotShowIn: GNOME" may help here, but I guess that some users of GNOME may want to sort applications to categories using not standard ways.

mikhailnov commented 4 years ago

Here is how it is in lsp-plugins 1.1.15 + XFCE + Whisker menu:

image

image

It is just fine.

sadko4u commented 4 years ago

Maybe they should be put inside "" tag

Hmmm. I currently don't understand that XML programming logic. How does it work? Do we really need to use it?

Also, the open question is: why GNOME didn't show LSP icon for applications.

sadko4u commented 4 years ago

Interesting message today from openSUSE package manager:

Could not parse file "/usr/local/share/applications/in.lsp_plug.lsp_plugins_sc_mb_expander_lr.desktop": Key file contains line ?OnlyShowIn:X-lsp-plugins;? which is not a key-value pair, group, or comment                                  
Could not parse file "/usr/local/share/applications/in.lsp_plug.lsp_plugins_graph_equalizer_x16_mono.desktop": Key file contains line ?OnlyShowIn:X-lsp-plugins;? which is not a key-value pair, group, or comment                           
Could not parse file "/usr/local/share/applications/in.lsp_plug.lsp_plugins_sc_dyna_processor_mono.desktop": Key file contains line ?OnlyShowIn:X-lsp-plugins;? which is not a key-value pair, group, or comment                             
Could not parse file "/usr/local/share/applications/in.lsp_plug.lsp_plugins_spectrum_analyzer_x4.desktop": Key file contains line ?OnlyShowIn:X-lsp-plugins;? which is not a key-value pair, group, or comment                               
sadko4u commented 4 years ago

Was required to rollback OnlyShowIn parmeter because when I properly defined it, I got LSP Plugins menu hidden.

v-fox commented 4 years ago

Interesting message today from openSUSE package manager:…

How did you manage to build and package it in SUSE ? OBS post-build "quality checks" get pissy about desktop-files like they are rootkits, 'brp-30-desktop' script fails the build on any "problem" and there is no override, unlike other things that can actually break or compromise your system (stuff with rpmlint and BuildRequires: -post-build-checks).

It whines things like:

[   76s] calling /usr/lib/rpm/brp-suse.d/brp-30-desktop
[   76s] WARNING: '/usr/lib/rpm/brp-desktop.data/suse-screensavers.menu' does not exist
[   76s] WARNING: '/usr/lib/rpm/brp-desktop.data/applications-kmenuedit.menu' does not exist
[   76s] WARNING: '/usr/lib/rpm/brp-desktop.data/custom.menu' does not exist
[   78s] ERROR: No sufficient Category definition "Audio;X-lsp-plugins;" in /home/abuild/rpmbuild/BUILDROOT/lsp-plugins-1.1.15~20200403T160101.14175-57.1.x86_64//usr/share/applications/in.lsp_plug.lsp_plugins_spectrum_analyzer_x12.desktop 
[   78s] Please refer to https://en.opensuse.org/openSUSE:Packaging_desktop_menu_categories

Unless you do something like:

BuildRequires:  update-desktop-files
…
%install
…
for desktop in %{buildroot}%{_datadir}/applications/*.desktop; do
%suse_update_desktop_file -r ${desktop} AudioVideo Music
done

But that clutters the menu.

sadko4u commented 4 years ago

@v-fox I haven't build package for OpenSUSE. I've just noticed this message while installing another applications. That's why I decided first to correct and then to remove OnlyShowIn parameter in *.desktop files.

sadko4u commented 4 years ago

Available in 1.1.17 release!

BrunoVernay commented 4 years ago

In Fedora 32 - Gnome, the LSP desktop entries:

I used to ask on https://ask.fedoraproject.org/t/how-to-manage-hundreds-desktop-entries/7444 but found the answer elsewhere ..

sadko4u commented 4 years ago

@BrunoVernay I believe it's a Gnome-specific issue. All other DEs behave in usual way: they create a menu item called LSP Plugins and all other elements are sub-menus of this menu item: image

I don't know why GNOME designers decided that their use case is better but I can admit that currently we have troubles with GNOME environment only.

mikhailnov commented 4 years ago

I did not check but probably any DE or widget that tries to make a dashboard with application icons will have this problem: GNOME, Deepin, KDE's full screen dashboard, Unity, SimpleWelcome etc. (don't know how people work with such a mess in application menus)

BrunoVernay commented 4 years ago

Here lsp-plugin-gnome.zip is a script that will create a folder in Gnome application overview (see screenshot). It works (Fedora 32, Gnome 3.36.2) and the script should be robust (can be launched multiple times, has some checks) It relates to https://developer.gnome.org/AppFolders/ .

I guess some documentation or Wiki could be helpful for the poor Gnome users ... Desktop INI file, menu XML files, directory INI files and now dconf database :-) I can help write something concise.

Screenshot from 2020-05-30 19-42-32

sadko4u commented 4 years ago

@BrunoVernay

Do you think that part of your script can be some way integrated into makefile build?

OMG. GTK doesn't follow X11 standard (related to Drag&Drop feature). Now GNOME developers don't follow the XDG standard.

BrunoVernay commented 4 years ago

I don't know makefile very well, but if you can call gsetting, you are good.

Now I would have let this for packagers. Looks like it is a job for RPM and DEB scripts, no? And just provides this script in the documentation (could avoid the xslt if the script is generated with the list of desktop files)

eeickmeyer commented 4 years ago

@sadko4u

OMG. GTK doesn't follow X11 standard (related to Drag&Drop feature). Now GNOME developers don't follow the XDG standard.

Yeah, they haven't followed the XDG standard for the application selection since 3.0. GNOME wants to forge their own way and not rely on what they consider antiquated methods.

@BrunoVernay

Now I would have let this for packagers. Looks like it is a job for RPM and DEB scripts, no? And just provides this script in the documentation (could avoid the xslt if the script is generated with the list of desktop files)

As someone that packages for both RPM and DEB, that might actually be the way to go. At least providing the documentation would be amazingly helpful. I know I've been considering making some sort of category system for those that wish to use Ubuntu Studio's packages on Ubuntu proper (GNOME desktop), and since gsettings is how that is done. DEB packaging in particular has gsettings-overrides scripts, but I'm not 100% sure if RPM has an equivalent beyond the %post section which could call gsettings.

Honestly, it's an interesting discussion and concept, and something I do plan on digging into at some point in the near future, in particular for Ubuntu's case. I don't package lsp-plugins for Fedora, but I'm sure a similar concept can be applied there.