bug in script desktop-menu? antiX 19.x 32bit/64bit

[Forum Admin Dave]

Helpful

Up

0

::

Sorry I should have specified more clearly about the theme. I was wondering which Gtk icon theme are you using?

Computers are like air conditioners. They work fine until you start opening Windows. ~Author Unknown

[Member Robin]

Helpful

Up

0

::

@Dave Sorry I’ve misread you. Wasn’t aware you refer to the Icon theme and not to the desktop theme.

I have never changed this Symbol Theme cognisantly. But LXAppearance 0.6.3 from antiX control center tells me that I do use the “ROX” symbol theme.
So I tried to switch to another symbol theme from the list, I arbitrarily have cosen “Adwaita“. No change, the very same symbols are not displayed when using the new script version. Using 1.0 (or calling entry.getIcon() a second time) restores them to the menu.

Same goes for the symbol theme “Tango“.

So I switched to “antiX-numix-squre” symbols.
This brings back some of the missing symbols, but some others still are displayed as missing.
Now there are missing the icons for the entries:

Change wifi program
Set up live persistence
Configure live persistence
Search Bar
Control Center
Rox Filer as Root

Here again, running 1.0 version (or calling entry.getIcon() a second time) brings them back.

Finally I switched to “papirus-mini-antiX“. This time no symbols were missing when using the 3.2 version of your script.

These are all symbol themes I found to be present there, I didn’t install any additional theme. Only the last one seems to be completely functional, all the others fail with the new version to set all icons in the menu correctly, as long as the above mentioned call is not repeated. The misbehaviour when using other symbol themes than papirus-mini-antiX is reproducable.

Windows is like a submarine. Open a window and serious problems will start.

[Member marcelocripe]

Helpful

Up

0

::

Dave, I applied some commands in a joint test with Robin.
Tests took place on antiX 21 full 64bit on a LiveUSB without persistence, I applied the below commands in IceWM, JWM and Fluxbox window managers, it did not change the size of the icons after the commands. I hope these tests are helpful.

– – – – –

Dave, eu apliquei alguns comandos em um teste conjunto com o Robin.
Os testes ocorreram no antiX 21 full 64 bits em um LiveUSB sem persistência, eu apliquei os comandos abaixo nos gerenciadores de janelas IceWM, JWM e Fluxbox, não alterou o tamanho dos ícones após os comandos. Eu espero que estes testes sejam úteis.

demo@antix1:~
$ desktop-menu –version
desktop-menu version 3.0

demo@antix1:~
$ desktop-menu –write-out-global –icon-size=48
Writing Menu: fluxbox
Writing Menu: icewm
Writing Menu: jwm
demo@antix1:~
$ desktop-menu –write-out-global –icon-size=24
Writing Menu: fluxbox
Writing Menu: icewm
Writing Menu: jwm
demo@antix1:~
$ desktop-menu –write-out-global –icon-size=96
Writing Menu: fluxbox
Writing Menu: icewm
Writing Menu: jwm
demo@antix1:~
$ desktop-menu –write-out-global –icon-size=16
Writing Menu: fluxbox
Writing Menu: icewm
Writing Menu: jwm
demo@antix1:~

[Forum Admin Dave]

Helpful

Up

0

::

@Robin,
Ok now I can see the problem and verify that the logic in the script is working correctly. From what I can see testing here the fix of copying the line to replace the missing icon only works for icewm as icewm is capable of finding icons itself. This does not fix it for the other window managers correct? Also from my testing in icewm, icewm searches /usr/share/icons/ and picks the first instance of the icon matching the text from the menu file for the specified icon. This does not actually follow the icon theme selected. Now we can probably make desktop-menu mimic what icewm does, but perhaps it is better to address / fix the icon themes?

@marcelo
I am not certain why the option does not work anymore at the moment.
Could we record the icon size bug on the gitlab project issue page?
I feel as though this may be unintentionally forgotten amongst other issues expressed here.

Computers are like air conditioners. They work fine until you start opening Windows. ~Author Unknown

[Member marcelocripe]

Helpful

Up

0

::

I am not certain why the option does not work anymore at the moment.

The tests took place with version 3.0 of the desktop-menu program that comes in the antiX 21 full 64-bit ISO without updating.
Robin sent me version 3.2 of the desktop-menu program, it made the icons show in ROX and Adwaita themes (didn’t show the GUVCView icon), in Numix theme all icons worked in IceWM, JWM and Fluxbox window managers.

I could not test version 1.0 of the desktop-menu program, due to the message below:

$ desktop-menu-v1.0 –write-out-global
bash: /usr/local/bin/desktop-menu-v1.0: /usr/bin/python: wrong interpreter: No such file or directory
demo@antix1:~

Dave, if it’s possible for you to participate in Libera.Chat on the #antiX-translators channel, we can do the tests together, in addition to being very easy to communicate instantly with the automatic translation that Robin managed to develop to work in HexChat.

Could we record the icon size bug on the gitlab project issue page?
I feel as though this may be unintentionally forgotten amongst other issues expressed here.

I don’t know what the URL to log the problem is.
I was able to log the issue on GitHub from JWM because there is an “Issues” button in the Fluxbox there is no “Issues” button and I don’t know what to do in these cases.

– – – – –

I am not certain why the option does not work anymore at the moment.

Os testes ocorreram com a versão 3.0 do programa desktop-menu que vem na ISO antiX 21 full 64 bits sem atualização.
O Robin me enviou a versão 3.2 do programa desktop-menu, este fez os ícones serem exibidos nos temas ROX e Adwaita (não exibiu o ícone do GUVCView), no tema Numix todos ícones funcionaram nos gerenciadores de janelas IceWM, JWM e Fluxbox.

A versão 1.0 do programa desktop-menu eu não consegui testar, devido a mensagem abaixo:

$ desktop-menu-v1.0 –write-out-global
bash: /usr/local/bin/desktop-menu-v1.0: /usr/bin/python: interpretador incorreto: Arquivo ou diretório inexistente
demo@antix1:~

Dave, se for possível a sua participação no Libera.Chat no canal #antiX-translators, poderemos fazer os testes em conjunto, além de ser muito fácil a comunicação instantânea com a tradução automática que o Robin conseguiu desenvolver para funcionar no HexChat.

Could we record the icon size bug on the gitlab project issue page?
I feel as though this may be unintentionally forgotten amongst other issues expressed here.

Eu não sei qual é o URL para fazer o registro do problema.
Eu consegui fazer o registro do problema no GitHub do JWM porque existe o botão “Issues”, no Fluxbox não existe o botão “Issues” e eu não sei o que fazer nestes casos.

[Member Robin]

Helpful

Up

0

::

#1 @Dave Your suggestion to fix this issue in the themes itself looks promising to me, and from your explanations I’m sure this is actually the correct solution.

Marcelo has counterchecked my findings from antiX 19 (32bit) on antiX 21 (64bit), (many thanks Marcelo!). It turned out this display “bug” in menu is present there also, the very same icons are concerned in the very same icon themes. And you are right, we can confirm the doubled call does fix it actually only for IceWM, not for JWM and fluxbox.

Now, I believe we should think about the best way how and in which place to fix it:

Obviously there are some icons simply not present in most of the icon thems antiX includes by default.
So we have to fix all of them to make it work. This actually should be done, even if I have no clue how or where this could be done.

Presuming, the themes present in antiX are once fixed that way, the result will be, that we have specific antiX themes, specially crafted by including the additional icons needed for not displaying the missing-icon symbol for all the mostly antiX specific additions.

But this would disclose users from being able to make use of default full icon sets (eg. from gnome-look.org) at all. All these will display this “missing icon” symbol in the menu. We should consider there is a “install” button in our control center present, encouraging the user to try other icon sets.

So I believe we have to find a way to be still compatible with the default full icon sets available on the web.

One option is we’d use statically linked icon paths in the .desktop files for the applications not present in default icon themes. I’ve noticed icons set this way insetead of using gtk named icons are actually displayd correctly always when switching icon themes, even when not being part of these themes. But there is a drawback handling it this way, since it would exclude the application icon being set correctly in case there is actually a representation for it present in a theme. So this is no real solution.

Another option is we provide this function in a way being error tolerant for missing icons in a theme, e.g. similar to the way IceWM fixes this, or by any other method. It dosn’t help users at all displaying the missing icon symbol in our menus. There is nothing a user could do about it, besides not using the respective theme, which locks user in only to use the specially “antiX-ready” prepared themes instead of being able to make use of all the “full” themes present out there.

A possible way out of this double windmill could be (which is my proposal to solve this issue): Let’s use the correct way you’ve implemented it as the default, and add another command line switch like -​-fix-broken-themes which activates the search for missing icons from other themes. Sure, This function needs to be designed to work for all our supported window managers. Then I’ll add a corresponding checkbox to my gui script, so the antiX user has the choice to activate it when he wants to use icon sets not speciffically prepared for the use with antiX to avoid having all these missing icons symbols displayed in his menus as long there is some kind of matching icon present somewhere. I believe this is useful, even when this will cause some icons from wrong icon themes being used. A bird in the hand is worth two in the bush.

#7 Icon size actually doesn’t change using the -​-icon-size command line option. I can confirm this for antiX 19, and have mentioned this observation already some postings above. @marcelocripe : It’s a good idea to file it on gitlab issue site the way Dave has suggested and headed you to.

#8 (new): Marcelo made me aware the icons are refreshed only in the Programs sub menu. So the Icons don’t match with the ones in the other sections of the menus, making it difficult for users to correlate them correctly. Moreover in case a user wants to apply specially designed icon themes this can be annoying, since the design is applied incomplete only to the menu.

Windows is like a submarine. Open a window and serious problems will start.

[Member marcelocripe]

Helpful

Up

1

::

@marcelocripe : It’s a good idea to file it on gitlab issue site the way Dave has suggested and headed you to.

Issue It is not possible to change the size of menu icons in IceWM, JWM and Fluxbox window managers.

[Forum Admin Dave]

Helpful

Up

0

::

Please not I have not fully read the replies at this moment.
Just making a post to mention that there is a specification to follow for icon function as shown here. https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html
The directory before hicolor IIRC was /usr/share/pixmaps/ which is where the script defaults now for icons. This can easily be changed to the hicolour directory or have the hicolour directory in addition to the pixmap directory.

Computers are like air conditioners. They work fine until you start opening Windows. ~Author Unknown

[Member Robin]

Helpful

Up

0

::

Many thanks for this enlightening link, Dave. Still studying it, to understand the basic mechanisms of these themes and learn about the expected default paths.

Just a short additional thought: Possibly it might be desirable under the aspect of practicability from the perspective of users to have the default behaviour of the script to fill up any missing icons in case there is a chance to look up something suitable, not showing the missing icon symbol in menus by default, and then adding a command line option like e.g. -​-strict to deactivate this automatic fillup, displaying all the “missing icon” symbols again. I mean, just the other way around to my original proposal, instead of -​-fix-boken-themes.
I believe it does make more sense not to bother users with missing icons in a theme at all by default.

Meanwhile I’ve checked some arbitrarily chosen “full” icon themes found on gnome-look.org and xfce-look.org. Non of them are usable in antiX due to missing icons. So if we want to enable users to profit from these resources (and maybe other resources I don’t know of), we actually need to change the behaviour of the most recent script version in some way.

Windows is like a submarine. Open a window and serious problems will start.

[Forum Admin Dave]

Helpful

Up

0

::

Please see here: https://gitlab.com/antiX-Dave/desktop-menu-antix/-/commit/a8dcf8bba1831b6565e113a720112e077b126afc for changes to work similar to icewm and retrieve an icon from any theme (or any other directory if specified in the variable) if one is not available in the preferred theme. If the icon not matching the selected theme is too much of a bother to people we can add the –strict option as suggested and have the missing icon or no icon.

Computers are like air conditioners. They work fine until you start opening Windows. ~Author Unknown

[Member Robin]

Helpful

Up

0

::

Many thanks, Dave. Looks great.

Dave wrote:

If the icon not matching the selected theme is too much of a bother to people

If you believe we don’t need the -​-strict option, just drop it. It was meant for easy recognising actually missing icons in themes, marked in an eye-catching way by the “missing icon” symbol, in case somebody wants to create antiX-ready full icon themes like papirus-mini-antix based on an existing full icon theme.

Two suggestions from a quick first test of ver. 3.25 on antiX 19 (32bit):
#A: Quote from your link: »The supported image file formats are PNG, XPM and SVG«

so I believe you could replace/complement the expression in line 387

387 if filename.endswith('.png')

by the tuple

387 if filename.endswith(('.png', '.svg', '.xpm'))

to let it see these file types also. At least svg is widely common meanwhile.

#B: Declaration of the new variable icon is missing.

$ desktop-menu-3.25 --write-out-global
Writing Menu: fluxbox
Traceback (most recent call last):
  File "/usr/local/bin/desktop-menu-3.25", line 409, in <module>
    build_menu()
  File "/usr/local/bin/desktop-menu-3.25", line 265, in build_menu
    process_menu(menu)
  File "/usr/local/bin/desktop-menu-3.25", line 204, in process_menu
    process_menu(entry)
  File "/usr/local/bin/desktop-menu-3.25", line 204, in process_menu
    process_menu(entry)
  File "/usr/local/bin/desktop-menu-3.25", line 204, in process_menu
    process_menu(entry)
  File "/usr/local/bin/desktop-menu-3.25", line 233, in process_menu
    icon = find_icon(de) or default_entry_icon
  File "/usr/local/bin/desktop-menu-3.25", line 126, in find_icon
    if not icon:
UnboundLocalError: local variable 'icon' referenced before assignment

please add e.g. in line 112 right at the beginning of the function find_icon

...
111 ...
112 def find_icon(entry):
113     global icon
114 ...
...

which will fix the issue. (Please double check whether this is the correct place, I’m not that exprienced in python.)

Windows is like a submarine. Open a window and serious problems will start.

[Forum Admin Dave]

Helpful

Up

0

::

OK, changed as you say in my gitlab. I have no idea if all the window manager support all the image formats however (keep in mind there is also an openbox template that was made in the past).

Also added the –theme-only to the icon section to reference icons only from the gtk icon theme in use rather than any icon theme. This also uses the /usr/share/icons/hicolor/ and /usr/share/pixmaps/ directories as these are fallback directories where applications should at minimum place their icons. This was easy enough once I realized that the icon_dirs array only need to be changed rather than making a nested conditional statement.

• This reply was modified 1 year ago by Dave.

Computers are like air conditioners. They work fine until you start opening Windows. ~Author Unknown

[Member Robin]

Helpful

Up

0

::

Update:

#2 @Dave I’ve sent you a merge request for ver 3.27 at gitlab, dealing with the option for different separators.
I’m aware Paranthesis won’t work in fluxbox, but there are some other choices available now. There was a proposal somewhere here in thread (I believe it was from iznit, can’t find it right now) to escape the closing paranthesis by a slash or backslash. Checked this, at least in IceWM it won’t work, the slash will get displayed. Also tried to use similar UTF8 characters (u_ff08, u_ff09) instead of default paranthesis character, these won’t display in IceWM at all. Which means: all other non default UTF8 separators as proposed by iznit won’t display also probably.
So the solution I’ve chosen might be best what we can achieve here. Please feel free to improve my python coding style if needed.

#1 I have checked your most recent ver. 3.26 from gitlab on antiX 19 32bit for missing icons issue, while Marcelo performed the very same testing on antiX 21 64bit yesterday evening.
We can confirm it works fine in IceWM and JWM both, while still not all icons are filled up in fluxbox. (see screenshot)

Informational:

Moreover it turned out fluxbox doesn’t make use of svg files, while they are displayed fine in IceWM and JWM. Will try to ask fluxbox devs whether this behaviour can be changed to meet the recent specs from freedesktop.org. This is not an issue the desktop-menu script can do anything about, I believe.

Finally I noticed when using the icon theme install button in antiX control center (which originates from lxappearance) It won’t recognise tar.xz file types as valid icon theme files. Again, nothing what antiX could fix on its own, so I filed a merge request for this issue at lxde home on github. The lxde guys on IRC told me it might be long before this will get merged some day. Until then users need to manually extract the respective archives and copy the contents e.g. to the ~/.icons folder (or /usr/share/themes/ ).

—
Screenshot below shows adwaita icon theme on fluxbox antiX 21 x64 using 3.26 (shot was taken by Marcelo)

Attachments:

1. 

   Teste_Tema_Adwaita_no_Fluxbox_desktop-menu_version_3.26__1_.png
   

Windows is like a submarine. Open a window and serious problems will start.

[Forum Admin Dave]

Helpful

Up

0

::

@Robin and @Marcelo.

Please see here https://gitlab.com/antiX-Dave/desktop-menu-antix/-/commit/ead0d9e5bf005d9936819131ca0f83dd7513c6da for changes adapted from the merge request sent.

For the fluxbox issue, we could limit the script to only png file formats… but it would be best (and cleanest) to use an all png icon theme knowing that fluxbox does not support svg.

For lxappearance and .tar.xz, I took a look at the code and it seems the changes needed are in a merge/pull request already made a couple of days ago. https://github.com/lxde/lxappearance/pull/5/commits

• This reply was modified 1 year ago by Dave.

Computers are like air conditioners. They work fine until you start opening Windows. ~Author Unknown

[Member Robin]

Helpful

Up

0

::

#2 @Dave I really like the way you modified my proposal from the merge request by allowing people to define the separator character on their own. But now there are way too much blanks in the line when the term is embraced. Maybe this is fine for some languages, but in others it is definitely not. I had dealt with this problem by predefining some fixed patterns only (meant to be complemented by additional ones when needed), taking the different position of needed blanks into account. Please bear in mind, this is about designing the Menu GUI, kind of visiting card of antiX. So I’m a bit more precise here than I’d be when it’s about some hidden place a user comes across only accidentally.

--pattern="“”"
will look like:

First “ Second ” Third
First “ Second ”

instead of

First “Second”

So to solve this, fitting for all needs, I’d propose to replace the single -​-pattern option by two options, e.g. -​-separator-1= and -​-separator-2= which allows to have separators of different length including variable blanks instead of fixed length plus static blanks.

Examples:

--separator-1=" (" --separator-2=")"     →  First (Second)
--separator-1=" ( " --separator-2=" )"   →  First ( Second )
--separator-1=" · " --separator-2=""     →  First · Second
--separator-1=" " --separator-2=""       →  First Second
--separator-1=" (" --separator-2=") "    →  First (Second) Third
--separator-1=" ( " --separator-2=" ) "  →  First ( Second ) Third
--separator-1=" · " --separator-2=" · "  →  First · Second · Third
--separator-1=" " --separator-2=" "      →  First Second Third

and so on.

Some writen ideographic languages don’t know our blanks, so we need to allow for these languages even:

--separator-1="" --separator-2=""      →  FirstSecondThird
--separator-1="" --separator-2=""      →  FirstSecond

We could even make it completely flexible by allowing four separators instead of two, e.g.:

sep_1 + name + sep_2 + gname + sep_3 + cname + sep_4

Examples:

[--separator-1=""] --separator-2=" “" --separator-3="” (" --separator-4=")"
→  GenericName “Name” (Comment)

This would allow languages reading from right to left to add something like brackets to their “end” of the line:

--separator-1="(" --separator-2=") " [--separator-3="" --separator-4=""]
→  (emaN-cireneG) emaN

--separator-1="(" --separator-2=") ”" --separator-3="“ " [--separator-4=""]
→  (tnemmoC) “emaN” emaN-cireneG

So this method is flexible enough to serve any needed strange kind of separator setting in any language.
(It allows the user even to set nonsens separators, but I believe we really don’t need to prevent this.)

--separator-2="………………" --separator-3="………………"   →  First………………Second………………Third
--separator-2="………………"                           →  First………………Second

If you know to allow reading all four variable length separators from one single option instead of four individual options, feel free to do it that way. I can’t find out how to do this in a straight and elegant way without detours in python.

--pattern "sep-1" "sep-2" "sep-3" "sep-4"

Additionally, please check, some minor fixings slipped through while applying the modifications intended by my merge request:

Line 394 states clearly the command line option is -​-names, while in line 60 (console help) it reads -​-name only, which is also accepted by the script, but not executed without notice.

Lines 67 trough 72: console help was modified slightly to include two-character orders in the help text.

This was fixed already in my request, but I didn’t mention it explicitly.

#3 Your new -​-category-filter= option is great. This not simply fixes issue #3 only, but brings additional flexibility for future. We should probably default to -​-category-filter=n for now to keep the known look from before. Where are the files located, in which the category entries are stored? Are these default .desktop files?

—

Concerning the install button: This merge request was actually written by me (see end of my posting above), even when I’m not sure whether I did everything correctly. It’s C code, and I do know pretty much nothing of it. At the lxde project’s IRC channel they encouraged me anyway to file my suggestions directly using a merge request, so I tried my very best not to mess up things.

Concerning the fluxbox svg thing: I believe we should not exclude svg in desktop-menu script, since this format follows the desktop icon specs, and is used commonly meanwhile, even when not present in fluxbox by now. Best is to inform users simply about not to use this type of icon themes on fluxbox, until fluxbox has implemented this.
I’ve checked the fluxbox source code, and I’m pretty sure it could get easily added the same way the png file type is processed: They use libimlib2 for png, it is referenced in /src/FbTk/image.cc file to ImageImlib2.hh. So I believe it is easily possible to add a similar section for librsvg2 and add something like an ImageRsvglib2.hh, which would probably solve the issue. Unfortunately, I can’t even add a basically working solution to file a merge request. I simply don’t understand the details of this C code, so I can’t add it correctly.
librsvg2 is present in antX 19 (at least on my system it is, I’m not sure whether this was originally present or whether it came with some application) and probably on antiX 21 also. Moreover, if I’m not mistaken, antiX has its own version of fluxbox.

fluxbox:
  Installed:           1.3.7-1~antix1

So could this svg thing get added in the antiX version eventually? (This is not pressing, informing users should be fine for the moment)

Windows is like a submarine. Open a window and serious problems will start.

[Author]

Posts