Possible bug in the script that generates antiX menus

[Member PPC]

I noticed recently (just yesterday) that a game – gnome’s 2048 does not come up in IceWM’s menu (in antiX 22, full, 64 bits, runnit edition). I though it was just me, but Marcelo said that there are some applications that fail to appear in the menu – https://www.antixforum.com/forums/topic/beta-new-faster-version-of-icewm-toolbar-icon-manager/#post-99725

Curious I tried the menus of all 3 window managers- I can’t find 2048 in the “Games” category of any of them, so I assume the problem is in the script that generates the menus, not in IceWM…

I’m attaching the offending .desktop file (if the forum software lets me)…

Edit: Marcelo’s assumption seems to be true: commenting out the “TryExec” line in the .desktop’s file and refreshing the menu does make it’s entry appear in the correct section…
As a workaround, I can create a script that goes trough all .desktop files and comments out lines that start with “TryExec=”, using sed… Not ideal, but does solve the problem, until the package that includes that .desktop file is updated…

P.

• This topic was modified 2 months, 3 weeks ago by PPC.
• This topic was modified 2 months, 3 weeks ago by PPC.

Attachments:

1. org.gnome_.TwentyFortyEight.desktop.zip

[Member PPC]

Helpful

Up

0

::

My proposed fix (test at your own risk and do back up the applications folder first!!!

#!/bin/bash
#Script to fix .desktop files that do not appear in the menu because they have the field "TryExec"
gksu 'Fix .desktop files'
cd /usr/share/applications
for file in *.desktop; do 
    if [ -f "$file" ]; then 
        echo "$file" 
        sudo sed -i 's/^TryExec=/#&/' $file
    fi 
done
sudo desktop-menu --write-out-global
echo Done.

[Member marcelocripe]

Helpful

Up

0

::

Segue na íntegra o texto referente a este assunto que eu postei no outro tópico:
Here is the full text on this subject that I posted in the other topic:

PPC wrote
For some reason the gnome game 2048 does not appear in IceWM menu, but it does come up on T.I.M. and now, it can be added to the toolbar… Maybe it’s a IceWM bug?

This is not an issue unique to the game “gnome 2048”, other .desktop files are not displayed in antiX menus, in particular .desktop files that have an entry dedicated to a specific desktop environment. Another example that is not displayed in the antiX menus is “desmume-glade.desktop” and “desmume.desktop”, both have the entry “TryExec=desmume-glade”. If the “TryExec=desmume-glade” entry is deleted, the text of the “Name” entry is displayed after the “sudo desktop-menu –write-out-global” command.

– – – – –

O PPC escreveu
For some reason the gnome game 2048 does not appear in IceWM menu, but it does come up on T.I.M. and now, it can be added to the toolbar… Maybe it’s a IceWM bug?

Este não é um problema exclusivo do jogo “gnome 2048”, outros arquivos .desktop não são exibidos nos menus do antiX, em especial os arquivos .desktop que possuem uma entrada dedicada a um ambiente de área de trabalho específico. Um outro exemplo que não é exibido nos menus do antiX é o “desmume-glade.desktop” e o “desmume.desktop”, ambos possuem a entrada “TryExec=desmume-glade”. Se a entrada “TryExec=desmume-glade” for exculída, o texto da entrada “Name” é exibido após o comando “sudo desktop-menu –write-out-global”.

[Member PPC]

Helpful

Up

0

::

@marcelocripe – have you tested my proposed “work around” (to automate commenting out the “TryExec” lines in all .desktop files)? If so, does it solve the problem of applications missing from the menus of antiX’s window managers?

P.

[Member marcelocripe]

Helpful

Up

0

::

Edit: Marcelo’s assumption seems to be true: commenting out the “TryExec” line in the .desktop’s file and refreshing the menu does make it’s entry appear in the correct section…

It wasn’t an “assumption”, it was a certainty, because I pointed out to you exactly the entry “TryExec=desmume-glade” in the .desktop file of “desmume-glade.desktop” and “desmume.desktop” that prevents the menu from being displayed in the antiX from these .desktop files, no matter which window manager is running.

There’s still the other problem, it’s entries dedicated to a specific desktop environment. These entries need to be commented out or deleted from the .desktop file for the “Name” entry text to be displayed after the “sudo desktop-menu –write-out-global” command.

It’s for this reason that I built the tutorial Game Emulators Shortcut Icons for antiX.

As soon as possible, I will help you with the tests in this new program of yours.

Thanks.

– – – – –

Edit: Marcelo’s assumption seems to be true: commenting out the “TryExec” line in the .desktop’s file and refreshing the menu does make it’s entry appear in the correct section…

Não era “suposição”, era certeza, pois eu te indiquei exatamente a entrada “TryExec=desmume-glade” do arquivo .desktop do “desmume-glade.desktop” e do “desmume.desktop” que impede de ser exibido o menu no antiX destes arquivos .desktop, não importando qual gerenciador de janelas esteja em execução.

Ainda tem o outro problema, são as entradas dedicadas a um ambiente de área de trabalho específico. Estas entradas precisam ser comentadas ou excluídas do arquivo .desktop para o texto da entrada “Name” ser exibido após o comando “sudo desktop-menu –write-out-global”.

É por este motivo que eu construí o tutorial Ícones de Atalho dos Emuladores de Jogos para o antiX.

Assim que for possível, eu irei te ajudar com os testes neste seu novo programa.

Obrigado.

[Member PPC]

Helpful

Up

0

::

@Marcelocripe – please compress and post here the .desktop files that fail to appear in the antiX menu, so we can make sure of what is causing this problem…

[Member marcelocripe]

Helpful

Up

0

::

Please download the .desktop files of “desmume-glade.desktop” and “desmume.desktop” from the URL above. I’ll need to search through my stuff for other .desktop files that have entries dedicated to a specific desktop environment that don’t work in antiX menus. This research will be time consuming, as I fix the problem in the .desktop files and publish it on archive.org with the translations de, fr, it, pt (a fake pt made by a Brazilian) and pt_BR.
If I’m not mistaken there is an internet browser (the light ones) that the .desktop file doesn’t work in antiX.

– – – – –

Por favor, baixe no URL acima os arquivos .desktop do “desmume-glade.desktop” e do “desmume.desktop”. Eu irei precisar pesquisar nas minhas coisas quais são os outros arquivos .desktop que possuem as entradas dedicadas a um ambiente de área de trabalho específico que não funcionam nos menus do antiX. Esta pesquisa será demorada, já que eu corrijo o problema os arquivos .desktop e publico no archive.org com as traduções de, fr, it, pt (um falso pt feito por um Brasileiro) e pt_BR.
Se eu não me engano tem um navegador de internet (aqueles leves) que o arquivo .desktop não funciona no antiX.

[Member hughtmccullough]

Helpful

Up

1

::

Coincidentally I have just had problems getting an entry for KiCad into the application menu. I’m not sure if this is relevant to this topic but it may be useful and if not you can always just ignore it. I found out that the problem was the naming of the desktop file. The file in /usr/share/applications after installation was called org.kicad.kicad.desktop (does that break with convention?). When I changed it to simply kicad.desktop I was able to get an entry in the application menu. I also had to add another item to the categories list in the desktop file as Science and Electronics weren’t recognised.

[Member PPC]

Helpful

Up

0

::

Hum… I created the initial version of MXFB’s (Mx Linux – Fluxbox) all categories menu- it was all in bash, and quite slow, but I think it did not have the flaws that our much faster python based script has- also, it moved entries from the initial list of all available apps, to the respective category. If any application(s) left, got moved to the “Other Apps” category, that was then created (other than that, that category does not come up one the menu)… Perhaps our script can do the same, so apps like that “Science and Electronics” one can be listed.

So far the script seems to have 3 bugs:
1- .desktop files with the “TryExec” line are ignored
2- .desktop files with several dots on their name are ignored (I can’t replicate this reported problem)
3- .desktop files with unknown categories are ignored (that makes sense, since antix menu has no place to put this residual categories)

Edit: my menu script eventually ran every time apt was run to upgrade/install something, and, if I recall correctly, it did not need elevated privileges – so that can be done (unlike what our current script requires).

NOTE: Please, Dev team, I’m not complaining about the current script – I used it for years, before noticing, by chance, what I presumed was a bug, and then people started pointing out some more problems. I do not know how to correct them, all I can do is suggest workarounds or give general ideas of how the script should work.

P.

• This reply was modified 2 months, 2 weeks ago by PPC.
• This reply was modified 2 months, 2 weeks ago by PPC.
• This reply was modified 2 months, 2 weeks ago by PPC.

[Member marcelocripe]

Helpful

Up

0

::

Hello PPC.

Tests have been successful with your program.
The attached text file “Desktop File Fixer Tests for antiX 18-02-2023.txt” has the details. After running your program, the files “desmume-glade.desktop” and “desmume.desktop” were displayed in the menus.

I still haven’t been able to locate the other problematic “.desktop” files in antiX in my stuff.

Thank you very much PPC.

– – – – –

Olá PPC.

Os testes foram bem-sucedidos com o seu programa.
O arquivo de texto anexo “Testes do Corretor de Arquivos Desktops para o antiX 18-02-2023.txt” possui os detalhes. Após a execução do seu programa, os arquivos “desmume-glade.desktop” e o “desmume.desktop” foram exibidos nos menus.

Eu ainda não consegui localizar nas minhas coisas os outros arquivos “.desktop” problemáticos no antiX.

Muito obrigado PPC.

Attachments:

1. Testes-do-Corretor-de-Arquivos-Desktops-para-o-antiX-18-02-2023.txt

[Member PPC]

Helpful

Up

0

::

Proposed “work-around” for .desktop files with periods on their names, that are reported not to show up in antiX menus:

find . -depth -name "*.desktop" -exec sh -c 'f="{}"; mv -- "$f" "${f%.desktop},desktop"' \;
for f in *desktop; do
dotless=$(echo "${f//./}")
 if [ $f = $dotless ]
  then
   echo No dots to remove from filename
    else
     mv -- "${f}" "dotless_${dotless}"
 fi
done
find . -depth -name "*,desktop" -exec sh -c 'f="{}"; mv -- "$f" "${f%,desktop}.desktop"' \;

This can be added to my previous script, and fixes 2 of the 3 reported causes of applications not showing up antiX menu…
NOTE: This is an extremely ugly hack!!! I do not recommend using it, it messes with .desktop files on the folder! Back them up before trying something so radical!!!

I can’t think of a way of just renaming strange categories to existing ones, so anyone with one of those .desktop files… you’ll have to manually edit them… I guess they are pretty rare…

Let’s hope there’s an easy fix for this problem, instead of depending on workarounds like the ones I propose…

Edit: I replaced the original code with a far better one, patched together from several on-line examples and a bit of creativity…

P.

• This reply was modified 2 months, 2 weeks ago by PPC.
• This reply was modified 2 months, 2 weeks ago by PPC.
• This reply was modified 2 months, 2 weeks ago by PPC.

[Member PPC]

Helpful

Up

0

::

After a nice night’s rest, here is a more secure script to remove periods from a file name (keeping files that just have one period untouched, it’s far safer):
NOTE: this can be easily adapted to remove periods (or dots) from any file name- some multimedia files have dots for spaces, and that may make them difficult to work with

#!/bin/bash
#fix for (.desktop) files with periods on their names, by PPC
#this can be adapted to remove dots from files with any kind of extension- but keeping the dot refering to the extension. It always assusmes that the last dot is related to the extension, and so, never removes the last dot 
cd /usr/share/applications

for f in *.desktop; do
original_file_name_without_extension=$(echo $f|awk 'BEGIN{FS=OFS="."}{NF=NF-1}1')
dotless_file_name_without_extentsion=$(echo $f|awk 'BEGIN{FS=OFS="."}{NF=NF-1}1'| tr -d ".")
 if [ "$original_file_name_without_extension" == "$dotless_file_name_without_extentsion" ]
  then
    result="$f has no dots to remove from filename, it will not be changed"
    else
     echo $f has dots in its filename, renaming it
     sudo mv -- "${f}" "dotless_${dotless_file_name_without_extentsion}.desktop"
 fi
done

• This reply was modified 2 months, 2 weeks ago by PPC.

[Member blur13]

Helpful

Up

1

::

Stumbled upon this thread after an update to spotify caused the menu item to disappear. And sure enough, it was because the desktop entry had a TryExec.

I’m going to list another “bug” (or area of improvement). It seems that desktop files in the ~/.local/share/applications/ directory are ignored when generating the menu. This is usually the directory that has the highest priority. Its a convenient place to put modified desktop files so that they dont get overwritten when there are updates to the programs.

[Moderator Brian Masinick]

Helpful

Up

0

::

Yet another, non related reason to believe that this thread probably does describe the problem and solution to the missing Applications menu – on my HP-14, both the antiX 22 and antiX 23 Beta 1 editions of antiX are missing the Applications menu.

However recently I was using one of my other computer systems that also has antiX and prior to some of the changes that may have unintentionally removed the entry I did indeed have the Applications menu, so I can go back to this discussion, review the entries and see if I can get it corrected using the logic described here.

I’m out and about now; I’ll check it when I get back to my computer systems.

--
Brian Masinick

[Moderator Brian Masinick]

Helpful

Up

0

::

I tried running the script here and I did not witness the reappearance of the Applications Menu, at least not as of yesterday.
I’ll try running it on all of my instances, and reboot them later and see if anything changes.
So far, if it’s fixed, I haven’t seen it; maybe I’m missing another step somewhere.

--
Brian Masinick

[Author]

Posts