Feature : Add Category for Linux DE

[srevinsaju]

Please add Categories: according to free desktop .desktop rules. For better classification of the apps. Currently on KDE, the desktop files created by pyshortcuts fall under lost and found.

Sent from my Galaxy Note2 using FastHub

[newville]

Um, how? I think we may not be able to (or necessarily want to) support even option available on every OS and Desktop environment. But if there is a concrete and well-explained proposal or PR for adding useful functionality, we'd be happy to consider it.

[srevinsaju]

https://standards.freedesktop.org/menu-spec/latest/apa.html

Modern DEs classify apps based on categories, just like a description box, , category in the desktop file is easy, as the code is based on python2, which I am not familiar with. But however I will try to create a pullrequest

[newville]

@srevinsaju Yeah I know that a .Desktop file can have many options. Do we want pyshortcuts to support them all? Honestly, I doubt we will ever support all of them. Even for the options that we might want to support, how do you propose we do that? What change to the API do you want to see?

Would we expected to somehow know what options might be valid? What would these options do for other OS and desktops?

[srevinsaju]

But categories is an important attribute of a .desktop file The shortcuts created by pyshortcuts fall under 'Lost & Found`. and thats not intuitive. I would like to keep my software under Utilities

And also, is there a solution for this: Even the icon looks blurry on KDE On the application menu, the icon is not found~!

On Linux, a svg file is a preferred icon. when i try to use .svg it automatically appends .ico to iy

[srevinsaju]

24

[newville]

@srevinsaju um, yes I understand why you think you want "Categories" added to the .desktop files on linux. You made that point -- your choice of a Linux Desktop environment is not interpreting the files placed in $HOME/.local/share/applications the way you want them to be interpreted. You do not need to post images of your desktop.

What you seem to be not understanding is that we are trying to provide cross-platform code. Linux Desktops might organize the behavior of their choice of something like a "Start Menu" according to entries within a App.desktop file in `$HOME/.local/share/applications'. They might show up as "Lost&Found" in KDEs Start Menu, or they might show up as "Other" in some other Linux Desktop.

Those .desktop files can be altered by downstream applications or by the user themselves. One of the key points of pyshortcuts is that the desktop shortcuts made can be altered or removed by downstream apps and users.

I think we do not want to add a separate command-line option for every option that a .Desktop file might support. Do we care about the one called "Categories"? I have no strong preference. Should there be an additional command-line argument for this feature which, as far as I can tell, has no analog on Windows or MacOS? I'm not sure.

So: WHY "Categories"? And WHY NOT all the other options to .Desktop? Really, which ones should be supported?

[srevinsaju]

@newville

1) KDE is one of the most used desktop environment for Linux and it uses categories to classify their software. And, as per my requirement, I wanted my software to be mentioned in the Utility section. You may or may not merge my pull request, I have written the code down and I find no harm in merging the PR except for a few KB increase in the repo. But that's ok!

2) the python package is more useful if it is customizable. I can package a predefined .desktop file and ask it to copy the file, but we chose pyshortcuts due to its portability and my laziness to write a code. According to me, a package becomes more useful when it is more customizable.

3) I added the screenshot in the intuition, that you might have better understanding. If you would not like users to post screenshot, please add a issue format in GitHub to predefine issues according to the developers ideal

4) you may close the issue now, I only wished pyshortcuts to be better. But, I need to pursue my need, albeit, so, as the MIT LICENSE states, redistribution of modified codebase with attributions, hopefully, you will allow me to create another python package under another name, so that it might be useful to other developers like me.

Thank you.

Sent from my Galaxy Note2 using FastHub

[newville]

@srevinsaju Why do you keep arguing for this feature as if we do not understand why you might want it? We never said it wasn't important to you, we're just trying to decide if and how we might want to implement it.

The question is: do we want to add a "Categories" keyword that appears to only affect how some Linux desktop files are shown by default in a Start-Menu-like thing on those desktop environments that show them? I (writing from a Linux desktop where piles of shortcuts go to Desktop and DesktopStartMenuLikeThing->Other) do not have a strong opinion.

Why add "Categories" but not "DBusActivatable" or "MimeType"? Would those also be keywords to add to the command line?

How would you support multiple Categories from the command-line?
Should there be error-checking on the Categories?
Should there be a non-empty default value for Categories? What should that be?

Maybe the better approach is to provide a json or yaml-formatted file that has the "Desktop options", or even an example desktop file from which such extra specs would be read. That would support Categories or MimeType or whatever DesktopXX wants to use in the future, and would allow application-wide or user-selected preferences in how there start menus got configured.

If you're going to implement this, you have to address those questions.

[maphew]

There already exists the options of desktop_dir and startmenu_dir, which are categories by another name. Perhaps there is a way of leveraging these in a way that isn't creating distribution-specific special cases? (Or conversely going back the other way, a new category option that becomes *_dir.)

[newville]

@maphew Yeah, I agree with the wondering about a different way to do this. Note also that "desktop_dir" and "startmenu_dir" are selected by the user / app developer, not by the target desktop environment.

If I'm writing a library that will use pyshortcuts to create desktop shortcuts at python setup.py install time or within a conda-constructor script (and, to be clear, I actually do this), what would I do with "Categories"? I don't know what Linux Desktop the end-user might be using. I don't know what "Categories" are available and/or preferred. Can I use "Categories=MyProject" and have that show up in the menu? I don't think that would actually work... so: what are valid categories? are we checking these?

I do know that the end-user can move these files around and edit them if they want to. So, they go to a default location like "HOME/Desktop".

So, again, I'm not opposed to this but if we're going to add such a feature it has to be worked out carefully.

[maphew]

My conception, perhaps too simple, is one of

a) if either _desktopdir or _startmenudir are defined, e.g. scut(startmenu_dir="Utility" ...), populate my_script.desktop with category=Utility, and all else carries on as present.

b) incoming category="Utility" would turn into _desktopdir or _startmenudir.

In either case it would be the script writer's responsiblity to use a valid category name.

I think (a) is more straightforward.

[newville]

@maphew That would be OK to me. But I don't know what happens if someone uses scut(startmenu_dir="My Great App", ...). Does that add a "My Great App" section to the start menu? If so, I'd say sure let's do that.

I suspect it might not create such a new section (it didn't for my linux desktop, but it isn't KDE). In that case, it would probably go to some generic place on the Start Menu like "Other". It seems that @srevinsaju would not be satisfied with that.

I don't know how to tell what valid sections of the Start Menu would be or what to about that situation. Is there a way to force the creation of a Start Menu section on Linux desktops? I don't know how to do that.

[srevinsaju]

I apologise for the chaos caused by here, I will try to work on it independently. KDE will show it up on other if we give a random keyword, to check those coinciding is easy. The categories classification is used in LXDE, XFCE, LxQT, Cinnamon and MATE. So it is not limited to KDE. Anyways thanks, I am closing the issue.

[newville]

@srevinsaju You have not really answered any of the questions I asked or addressed the suggestion from @maphew. That's sort of how this open-source thing has to work. You can take this code and use it and modify it for your own use, or you can try to solve the problem in a way that works for other people too and share that. Yes, it is harder to get to a solution that everyone agrees on, but in the end, you'll have a better solution.

As we've said at basically every opportunity, we are not fundamentally opposed to this, we would just want to figure out how to do it right.

[srevinsaju]

@newville

what happens if someone uses scut(startmenu_dir="My Great App", ...) . Does that add a "My Great App" section to the start menu? If so, I'd say sure let's do that.

No, The desktop launcher does not allow custom made categories. See guidelines put by freedesktop.org in categories here https://standards.freedesktop.org/menu-spec/latest/apa.html

Is there a way to force the creation of a Start Menu section on Linux desktops?

It is possible, by writing a xml file as mentioned here https://askubuntu.com/questions/435806/how-to-create-a-new-category-in-the-gnome-menu, but that is not the need atm, or can be a future idea!!

Hope I answered all the questions, for the time being, I will be using my custom made pyshortcuts. I know the ideal opensource, and wanted to contribute to the project, and shared my idea as a pull request #24. It is the repo owner's wish to merge it or close it. You could implement an additional command to allow users to enter data to append to the . desktop file or .lnk. you may mark it on your checklist!! (A suggestion 😉)

Sent from my Galaxy Note2 using FastHub

[newville]

@srevinsaju

Hope I answered all the questions

Well, you didn't actually answer all the questions. Again, no one has ever disputed that adding categories might be useful, we're just trying to figure out how to do that in a sensible manner.

Using startmenu_dir to set a "Categories" seems like a reasonable approach to me, but there seems to not be an easy way to know if the selected category exists for the StartMenu of the installed account and so we don't know if it will "work" to not end up in "Other" or "Lost&Found" or whatever. No matter what category the user picks, we don't know if it will "work". That's not a highly compelling feature. Again, we're just trying to understand "how would we do this".

If you look at the previous work (issues, PRs) here, you will see that we've had similar struggles with how to do other things too. We understand if you're not interested in trying to solve the problem in a way that works for everyone, but that's what we're trying to do here.

[srevinsaju]

Ok, I am too interested in a way that solves the problem for everyone, btw, it is not a problem, it is just a feature. Hope you will come out with a great solution 😊

[maphew]

an additional command to allow users to enter data to append to the . desktop file or .lnk.

This has merit on the allow future flexibility front:

deskfile = {'Category':'Utility', 'FutureNewKeyword':'boo!', ...}
if deskfile:
    # write deskfile dict contents to desktop.file as `keyword=value\n` entries.

with pyshortcut not making any attempt to determine if the values are valid for the destination system.

[newville]

@maphew Yes, I agree! I do not want to support every possible Desktop entry as a separate keyword argument. Using a dict (or yaml file or ".desktop" stub) to mean "add all these options to the Desktop file" might be better.

I think we cannot enforce anything approaching "The category you called 'utility' does not exist" because we cannot really know that for every desktop environment. That means it will be common for desktop shortcuts to end up in "Other" or "Lost&Found" or whatever. But, an important point of these shortcuts is that the user can move/edit/delete/ignore them. Categories would be an attempt to put the shortcut in a good place on the start menu. It would not be fool-proof and it would not be final.

Anyway, I am much more sympathetic to "Let's add a dict-like structure for a set of options for Desktop files" than I am to "I need Categories Right Now".