Why system-wide fixing?

[ismaelgv]

Well, It's only a question that came to me analyzing this script. Why use system modification in '/usr/share/' and other system paths?

You can simply override system configuration writing .desktop files in '/home/$USER/.local/share/applications/'. This approach will avoid overwrites on fixed files by upgrading software in package managers. Additionally it offers better tracking of modified .desktop files.

This approach will let you include in Numix Icon theme auto-fixing at installation/upgrading time without messing with system files.

If you still want to fix whole system, you can still write in all users HOME local directory with root permissions or keep the current system.

Related to numixproject/numix-core#2546

[leoheck]

Good question, I agree with you @ChuckDaniels87 and the undo process can simply remove the user defined launchers.

[palob]

Sounds simpler than the current way indeed 👍

[Foggalong]

Does the system always use the local launcher over the global one? I was under the impression the preference was the other way around

[palob]

Yes, according to this and my experience (I do this a lot) the local launchers override the global ones.

[bilelmoussaoui]

What if the application has only a local desktop application ? We should only modify it?

[ismaelgv]

You can do the same as package managers do: rename it as '.desktop.old' and create a new one.

[bilelmoussaoui]

@Foggalong What do you think? Will take less time than #149

[Foggalong]

I was a bit skeptical at first, but I actually really like the idea. I'm just struggling to manage things at the moment. Just started at a new University and am simulatenously having to run Numix single handedly because everyone else is busy with other projects. A bit chaotic tbh, but I'll get around to it as soon as I can :)

[bilelmoussaoui]

I'm bit busy too, second year is much harder than the first one! i will see what i can do whenever i have some free time! and good luck with your studies

[bilelmoussaoui]

I will work on this as soon as #190 get merged; but just need a way to manage this :
If the desktop file already exists in $HOME/.local/share/applications/ we modifiy it , and if not we copy the desktop file and change the icon name?

[palob]

You mean a backup file in order to make a rollback possible?

[bilelmoussaoui]

Well, we don't really need to backup the file, as the we only change the icon name; and it's stored in the CSV file?

[palob]

But in case there are multiple entries for one app you'd have to save which hardcoded path got fixed somewhere.

[bilelmoussaoui]

A backup file will be an easy solution. Saving that in an other file + the file i used for hardcoded icons to fix #190 will make things complicated to debug later.. @Foggalong what do you think?

[bilelmoussaoui]

@Foggalong Just in case you still want to do this, i think it's a bad idea. The way we fix icons right now is the right way. The default icons are copied to hicolor theme, this way we fix the icons for all the users which is better than just fixing them for only one user..

[palob]

Currently though the fixing doesn't persist any app update + you need admin privileges (which not every user have access to).
Fiddling about in /usr/share/ "the realm of the package manager" how it's done with the hicolor theme is considered bad style by some.
Couldn't the script optionally copy the fixed launchers over to other users' $HOME directories?

[bilelmoussaoui]

Alright! Will implement that if the user does not the script as root. And we mention that on the README

[ismaelgv]

Does apps usually write .desktop files on /usr/local/share/applications?

/usr/local/share has precedence over /usr/share. Could it be possible to store global changes there?

[Foggalong]

Just as a heads up to all, I'm planning on doing a complete rewrite of the way this script works fairly soon. Gonna have a play around with different ways of saving changes locally and backing up files

[bilelmoussaoui]

@Foggalong If you're up to rewrite the script, please give python a try! it will make the code less complicated..

[Foggalong]

@bilelmoussaoui To answer this nearly 2 years later, any rewrite I do of this script will likely stay in bash. It's not necessarily because I think it's the best tool for the job, but I already do a lot of coding in Python for work so it's nice to have something a bit different. This (in theory) keeps my bash skills sharp while also not being a ridiculous language to use for the task

[ismaelgv]

@Foggalong is this issue still relevant or may I close it?

[Foggalong]

@ismaelgv Still relevant, it's one of the issues I hoped to tackle in the next version but haven't got around to finishing that off yet