- This topic has 24 replies, 8 voices, and was last updated May 28-3:48 pm by sybok.
-
Posts
-
iznit
difficulties:
1) Any customized [[[enhanced]]] desktop file may get overwritten when its package is updated
2) Most packages are maintained by debian and submitted changes may not be [[[probably wont be]]] backported to the current debian stable package
demonstration of solution:
https://git.devuan.org/iznit/custdesk/src/branch/master/custdesk_1.0-1_all.deb
only 3.6kb [[[for demonstration, contains only 3 customised .desktop files, custom EN Name= text]]]
suitable for both antix 19 and antix 21, both i386 and x64$ sudo apt install ~/Downloads/custdesk_1.0-1_all.deb
[[[ your “downloads” directory may be different ]]]After installing, if you have antix full version, visit the desktop menu [[[en-US]]] and notice that the Name text for mirage is now displayed as “#_mirage_#” and for inxi-gui “#_PC Information_#”
for purpose of testing:
$sudo apt remove mirage
then visit the menu and note that the entry for mirage is now absent [[[as expected]]], then
$ sudo apt install mirage
and revisit the menu to confirm that customized name string “#_mirage_#” is preservedfor purpose of testing:
$ sudo apt install pipenightdreams
[[[ a game, few MB ]]] then visit the menu to confirm custom Name string #_pipenightdreams_# has been appliedI do not know which characters [glyphs] are universally available across all fonts. Guessing the _ underscore [in the ASCII character set] is one of the few universal characters useful for a Name __ short description separator
Not suggesting to stop contributing translations to upstream maintainers, but this “custdesk” mechanism can deliver changes immediately. Also, if added to antix repositories….. and an updated antix-desktop-defaults-base [?] package listed custdesk as a dependency, the newly translated desktop files could be pushed to pre-existing installed systems.
A near-term goal would be to provide coverage of all .desktop files preinstalled in antix 21 full
marcelocripe
Iznit, thank you so much for this tutorial, I’m going to do some testing this weekend.
A near-term goal would be to provide coverage of all .desktop files preinstalled in antix 21 full
This work is in progress and it would be great if more natives of the English language and of all languages available in antiX can also participate in making improvements and corrections.
We need each person to contribute directly to Transifex in their respective language, if there is a country identifier, only contribute in that specific language. For example: there are languages en_US and en_GB, there are only two people native to the language en_US and there are no people native to the language en_GB in Transifex contribs. The more people who can contribute, the better the final result of the work will be and later we can update GitLab contribs with these improvements and corrections.Not suggesting to stop contributing translations to upstream maintainers…
I hope that the work of translating, proofreading and improving the texts of the .desktop files made by people can be sent to the “upstream maintainers”, I just don’t know how to do that. If we can make the upload to the “upstream maintainers”, these improvements and fixes could benefit even more people, including other GNU/Linux distributions that use the package. As I had written before, the languages that were translated by humans are: fr, fr_BE, de, it, pt and pt_BR, these languages I’m sure are not automatic translations from the internet translator. If there are more languages that have been translated by humans, it would be good to identify them here for everyone to be aware of.
– – – – –
Iznit, muito obrigado por este tutorial, eu vou fazer alguns testes neste fim de semana.
A near-term goal would be to provide coverage of all .desktop files preinstalled in antix 21 full
Este trabalho está em andamento e será muito bom se mais nativos do idioma Inglês e de todos os idiomas disponíveis no antiX também possam participar fazendo as melhorias e correções.
Nó precisamos que cada pessoa contribua diretamente no Transifex no seu respectivo idioma, caso exista o identificador do país, contribua apenas neste idioma específico. Por exemplo: existem os idiomas en_US e en_GB, tem apenas duas pessoas nativas do idioma en_US e não tem pessoas nativas do idioma en_GB no Transifex contribs. Quanto mais pessoas puderem contribuir, melhor será o resultado final do trabalho e posteriormente poderemos atualizar no GitLab contribs com estas melhorias e correções.Not suggesting to stop contributing translations to upstream maintainers…
Eu espero que o trabalho de tradução, revisão e melhoria dos textos dos arquivos .desktop feitos por pessoas possam ser enviados para o “upstream maintainers”, eu só não sei como fazer isso. Se conseguirmos fazer o envio para o “upstream maintainers”, estas melhorias e correções poderão beneficiar ainda mais pessoas, inclusive de outras distribuições GNU/Linux que utilizem o pacote. Como eu havia escrito antes, os idiomas que foram traduzidos por seres humanos são: fr, fr_BE, de, it, pt e pt_BR, estes idiomas eu tenho certeza que não são traduções automáticas do tradutor da internet. Se houver mais idiomas que foram traduzidos por seres humanos, seria bom identificarmos aqui para todos poderem tomar ciência.
Robin
A near-term goal would be to provide coverage of all .desktop files preinstalled in antix 21 full
@iznit : This is exactly what we are doing right now. We have all the strings of these files from antiX 21 and antiX 19 (both in “full”) at transifex already. And yes, we try to get in contact with tho original program authors for upstream the updated .desktop files including the new translations. But this doesn’t keep us from using the antiX special .desktop files immediately (see below).
Only since there is still a bug in my parsing script I had no time to fix (maybe I’ll have to rewrite it in python instead of bash for easier parsing), the merging after downloading the translated strings from transifex needs manual fixing the resulting updated .desktop files by now, which is quite time consuming (Many thanks @marcelocripe for your great job in fixing all the malformatted .desktop files!) Once this is done a first version of this installer package will be created for extensive testing.I believe there is an easy way to use antiX injected special .desktop files (until the original authors have once accepted the changes, or in case there is no response from them). They can get packaged alltogether into a single antiX-special-desktop.deb, not overwriting the original .desktop files but storing them in a separate subfolder e.g. /usr/share/antix-desktop-files (or wherever they stay untouched and don’t conflict with the original ones under control of the packages which installed them). Then we’ll place the needed symbolic links in /home/<user>/.local/share/applications (at least in the live version this is possible without violating the dont’t-touch-users-homes rule, the demo user is readymade within the ISOs I belive) and make sure they are present in /etc/skel also for new users. A simple bash script placed in antiX control center allows then to switch between original and special antiX version of desktop files, so user can simply select himself what suits him best.
Right now we are testing this method and developing the needed processes, and once it works as expected, we’ll come up here with it.for purpose of testing:…
Many thanks for the links, I’ll look into this once I’ve finished working on making desktop-menu script translatable.
I do not know which characters [glyphs] are universally available across all fonts. Guessing the _ underscore [in the ASCII character set] is one of the few universal characters useful for a Name __ short description separator
I believe there is no real problem. The upcoming version of desktop-menu not only include translations and multi user ability but will allow to set these separators (between Name, Generic Name and Comment) user defined and also allows him to define which of the entries he wants to have present in his application menu. So there is no need any longer to include everything into the .desktop files name entry. Consequently the name entry (as well as the other types of entries) will not include any separators probably. And since users can choose the separators themselves they will probably only use a selection from what is present and displayable on their systems. At least I have not seen any problems with some default separators on antiX 19 (e.g. → — × ÷ … · – ›‹ »« „” {} () [] etc.) or similar on antiX 19 full (32bit), Marcelo confirmed this for antiX 21 (64bit). Single exception is the default closing round bracket, which fluxbox wouldn’t display (needs probably a workaround fix in desktop-menu specially when writing out files for this window manager to escape this character in fluxbox files).
This is also subject to be tested extensively before packaging for broader usage.https://www.gnu.org/software/freefont/coverage.html
Windows is like a submarine. Open a window and serious problems will start.
iznit
They can get packaged alltogether into a single antiX-special-desktop.deb, not overwriting the original .desktop files but storing them in a separate subfolder e.g. /usr/share/antix-desktop-files (or wherever they stay untouched and don’t conflict with the original ones under control of the packages which installed them).
Robin, yes “custdesk” package closely matches what you describe here.
In actual use, instead of 3 sample files, the payload would be all desktop files containing the customised transifex strings.custdesk package installs the .desktop files to [[[subdirectories of]]] /usr/lib/custdesk
and does not disturb any .desktop files pathed under /homecustdesk installs an apt hook to call a script which runs immediately before the update menu hook.
Here you can read the tiny [[30 lines]]] script called by the hook:
https://git.devuan.org/iznit/custdesk/src/branch/master/custdtfiles.sh@iznit: Your approach looks interesting to me. But if I’m not mistaken, this will not work on multi user systems, since the desktop files get overwritten in /usr/share/applications instead of allowing users individually link either to the original set of files or to the special antiX set.
So if one user activates this, all other users will lose the original entries in their menus the very moment also, and no way to restore them (which would in turn reverse the change for all the users again who had applied your package.) So I believe this needs some more reflection how this can get implemented properly. I had to deal with the very problem in desktop-menu, and I really don’t know whether my solution is best what can be achieved, but at least it has proven to work reliable and stable on multi user systems. What I did is: I’ve added a setup function in order not to touch the users homes on package installation. Once installed, no touch of users homes is needed anymore for proper operation, and if set in /etc/skel also, new users will have set it up properly from the very beginning. As said before, this will be available via a gui frontend meant to get included in antiX control center (running the desktop menu script as backend), so users can switch to what they like best easily. Maybe this method would work here also for the desktop files, having a switch in control center allowing each user to select whether he rather wants the original desktop files or the special antiX ones or any other set of .desktop files (simple symbolic links are enough, no need of creating dozens of identically file copies for each user), without running into conflicts with other packages. (I believe it is better to have it run user specific also for the .desktop files, since there may live more than two variants of file sets a user could choose from.) For new users (from etc/skel) there is no problem, it can be set as system default, and an existing user (not Live demo user, which is preset also in ISO, so no problem) needs to run the script once in its setup mode to turn on the modifications by applying the needed changes in his home folders which is to be considered as rule conform, since user himself starts this, knowing what he’s doing and he needs root privileges on the machine to be allowed for execution. On a single user system user himself can do it by sudo, and on multi user systems the system admin will have to decide whether or not to activate this feature for the users (or allow/disallow a dedicated user group for this setup task run by sudo) So user can very well be asked in postinstall script of the desktop-menu package already whether he wants the setup run for him y/n, and get informed he could also do it later on his own by calling… etc.). I could very well picture this method getting applied on the user specific set of .desktop vs. original set of files also, but I’m keen to learn whether there is an even better way to achieve the multi user system compatibility while not dropping functionality or violate the rule “don’t-touch-users-homes”.Windows is like a submarine. Open a window and serious problems will start.
Here is my approach capable of handling multiuser antiX systems as well as single user systems. First “official” version (but don’t forget, this is a community side project, not official antiX development), so some improvements will come still, but basically the script does now what is expected.
Dealing with multi user environments renders it indispensable to work on a per user base. My first idea to simply place a single symbolic link link in ~/.local/share/applications pointing to an antiX desktop files system subfolder turned out to be non functional: The window managers kept duplicating the menu entries instead of replacing them as soon the symbolic link to a populated folder was placed and the menu was refreshed. But when placing the links one by one in the very ~/.local/share/applications folder directly instead of a subfolder the window managers behave differently: All links (and files) present in this very folder do actually replace the original system wide use of .desktop files for menu entries, which goes with the freedesktop.org docs about folder hierarchy. So this script does now exactly this, creating symbolic links to all the files present in antiX desktop files system folder, which will get installed by the package to come.
Potentially existing desktop files of the same file name as a file in the package which needs to create a link will get backuped by the script to an antiX specific backup name unlikely being ever used by the user, and restored when the unset options of the script are run. After setting or removing the symbolic links the script lets the desktop get refreshed by Daves desktop-menu script. (Needs at least desktop-menu ver 3.32c)
This way all .desktop files in system folder for which no counterpart was found in the antiX desktop file set will stay in use simply. So the integration is seamlesly. And we will not conflict with any original files installed by the packages, and no apt-hook is needed to restore them again and again after system or program updates.
For system wide operation sudo or root access is needed, so on multi user systems the privileges to run the script in its different modes (single/global) can be set granularly by the system administrator, while on a single user system the owner has full access to all functions without sudo in single mode, sudoed for global mode (which he probably will never need.).
Download link for testing: desktop-files-antiX
When testing (Best is to use an aniX Live USB stick for this):
1.) Copy the script file into /usr/local/bin folder an make it executable.
2.) Create a system folder /usr/share/antiX-desktop-files/applications (case sensitive!)
3.) Put some modified desktop files into this folder (you’ll need root access e.g. by using sudo)Please check extensively. This is bughunting stage right now.
When now running the script using one of its set options the respective menu entries will get replaced by the modified ones from your test sample desktop files. No other entries will get touched.
Further improvements will probably bring us the ability to choose between multiple sets of desktop files on a per user base, and a GUI frontend. Moreover the strings within the script will get uploaded to transifex for translation, they are marked already within the script.
And then the desktop files Marcelo has fixed with infinite endurance will get packaged for use together with this script.
So long
RobinWindows is like a submarine. Open a window and serious problems will start.
sybok
Hi Robin,
I looked at the script but did not test the overall functionality.
I propose some readability and minor changes:
1) The main loop over passed variables modified to iterate over all passed characters.
2) Use local variables to make the purpose of function arguments more clear.
3) Improve/Fix indentation.
4) Double quote non-expanding (without wildcard(s)) values/parts of variables (bad experience when names contain spaces… better safe than sorry).
5) There is a ‘TODO/FIXME’ question on you as the author of the code regarding ‘break’ in a loop (line no. 80 of my file)I usually use ‘shellcheck’ utility to perform a code check of BASH scripts; it helps me to spot some parts prone to potential errors.
(BTW, similar tool for python is ‘pylint’.)WARNING: I commented out the 1st line in the code to avoid upload issue before adding a TXT suffix.
- This reply was modified 11 months, 2 weeks ago by sybok.
- This reply was modified 11 months, 2 weeks ago by sybok. Reason: Warn of upload-specific modifications
marcelocripe
Sybok, yesterday’s tests, together with Robin via HexChat on the antiX-translators channel, were very encouraging. It was great to be able to see in the antiX 21 full 64-bit menus the corrected/improved/translated texts from the .desktop files in pt_BR that are available at GitLab contribs with just two or three terminal commands.
Thank you very much Robin.
– – – – –
Sybok, os testes de ontem, em conjunto com o Robin via HexChat no canal do antiX-translators, foram muito animadores. Foi muito bom poder ver nos menus do antiX 21 full de 64 bits com os textos corrigidos/melhorados/traduzidos dos arquivos .desktop em pt_BR que estão disponíveis no GitLab contribs com apenas dois ou três comandos no terminal.
Muito obrigado Robin.
Many thanks, @sybok , for your feedback and your proposals for improvement.
#1: By now the script takes only a single option without any arguments at a time, so no need to count and collect them. I’ve replaced the default loop by a line checking whether user tried to file more than this single option. In case some day we’d need actually options taking additional arguments, or more than one argument at a time, your proposal to collect them is great, since it allows user to see all the errors at once, instead of presenting him one by one when he has fixed the first and then the next issue in his line. But I believe to make it work it will need some more modifications than you’ve added in your proposal: The function calls need to get moved out of the loop also, otherwise the script will start working even when not having parsed the command line completely if the wrong option was not in the first position in user’s input.
#2: Yes, I’ve changed this. As long as the script is that overseeable in size there is no urgent need to make them local, but you are right, when it grows the global variables will be difficult to manage. Easily somebody later could mess up things by reusing a variable already in use at this very moment on runtime when adding something. So better setting local what is not meant to be global, avoiding later trouble.
#3: Even when bash doesn’t care about indentions like python does, I’ve fixed the indentions for a nicer look. Hope I didn’t miss one 🙂
#4: I’ve noticed this need to allow blanks in filenames and paths already and had fixed it partly for the non wildcards. Wasn’t aware I actually can exclude the asterisk from the quoting, so I omitted these strings when updating this morning. From reading your modifications file I’ve learned it is easily possible to quote them also by leaving the wildcard outside of the quotes. So I’ll add this from your proposal. Fixed now completely. Many thanks! (I remember now I knew this technique before, but simply forgot about it. So it was really good to see it again being used in your proposals.)
#5: You are right, I actually meant to continue rather than break. Fixed now. Many thanks for making me aware of my careless mistake. This was the reason for not all symbolic links being removed in Marcelos tests (many thanks @marcelocripe !) after hitting a folder accidentally present in the parsed folder.
After thinking a second time about it, I’ve added this check to the link creating functions also, since if we’d actually want to allow subfolders to be treated also, we’d have to check the files contained individually. Otherwise we could easily let vanish some entries from menu for which we don’t have replacement files. Basically we could just drop the check, since it will rarely happen somebody creates a folder, a pipe or whatever with the extension .desktop within the /usr/share/desktop-files-antix/applications subdirectory, (I’ve added this restriction of file name extension to the selection by name already), but as you said: better safe than sorry, so I’ve added this check to the other loops concerned also.As you also have remarked within your proposal file, the bash parametric expansion would only catch a single extension (you can do it this way, but it’s a bit more intricate to make it work for all cases), this is what I had found also before and so I’ve used sed here instead. And yes, I’m used to the “picket fence” in sed, so no need to replace the slashes, as long the slash isn’t present within the replacement string. Btw, using your style here doesn’t make it more readable. And it will stall if @ would be needed within replacement string also, so we have no improvement by replacing it. There is an easy workaround: use
'"${backup_suffix/\//\\/}"'
which masks all the violating slashes and protects blanks. (Or with your delimiters:
sed 's@\(..*\)'"${backup_suffix/\@/\\@}"'$@\1@'
which is not any better under the aspect of readability). And no need to escape the escaping backslashes also. But as long we can make sure not to have present the incriminated characters (whichever sed delimiter we choose) in our (in this case static) replacement string, there is no need to apply bash parametric pattern substitution for escaping the delimiters before feeding it to sed. Moreover slashes are not allowed in filenames, so no problem here at all, the variable will never contain a slash (but could contain an @ very well, which is valid in file names.).Remark on line 51 and 73 of your proposals: This is not python, so you can’t use the expression like an object. It has to sit within the loop to know about the changing contents of i.
Additional fix in the updated script version: fixed issue with multiple users having another user’s name as part of their user name. Made sure grep will only return the very line of the user, not all lines containing his name accidentally as part of other names or other field contents present in the file. (added line start anchor “^” as start of the search pattern and default pwd file separator “:” at the end of the search pattern, so only the line containing the precise user name in its first field will get returned for further processing.)
Never knew shellcheck or pylint nor used them until now. Will take a look at them, maybe these are useful tools.
Windows is like a submarine. Open a window and serious problems will start.
sybok
Hi, Robin,
A) sed: ‘@’ vs. escaping slashes / “slashes are not allowed in filenames”:
If the filename contains part of the path, then a problem could occur, that’s why I use ‘@’ but you are right, I have seen ‘@’ in a file recently!B) Lines 51 and 73:
Yes, my dumb mistake, both lines should be moved to higher numbers inside the loop as you correctly pointed out.
I wrongly grouped them to the part where the other local variables are filled by arguments.C) shellcheck:
I usually call it as follows
f=[scriptname (without path)]; shellcheck "$f" > "shell_${f}"
to store the output of the analysis in a text file.
This is easy to search for in history and requires a single modification of the value of variable ‘f’ when reusing.Beware, shellcheck sometimes suggests double quoting when I do not want to because of expansion.
- You must be logged in to reply to this topic.
