Strange issue with App-select

[RobinMember]

Hi all,

I just ran into a strange issue with App-select from antiX main menu. Maybe somebody can help me to get an idea what I’m doing wrong, I hardly ever had used this (admittedly really useful) tool before, shame on me.

What’s my problem? I modified a .desktop file of a program by merely appending gksu to the Exec= line in front of the command. While this works perfectly fine in antiX main menu itself, and also when running the .desktop file from within zzzFM, this unfortunately doesn’t go for App-select. For me App-select keeps the former start command when opening App-select again from the antiX main menu, and tries to start the program unsudoed still for some strange reason, while the .desktop file in /usr/share/applications now reads differently. What’s going on here? Did I miss some command for updating a hypothetical App-select internal database, like refreshing the antiX menu is needed after modifying a .desktop file?

System data:

antiX 23.1 full runit 64 bit, fully apt-upgraded
$ apt-cache policy app-select-antix
app-select-antix:
  Installiert:           2.0.7

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

[RobinMember]

Update:

Works when moving the .desktop file completely from /usr/share/applications to somewhere else temporarily, then starting App-select (searching for the very program now no longer shows any result), closing App-select and moving the .desktop file back to /usr/share/applications .

When now starting App-select again, it will come up with the updated command and be able to run the application properly sudoed.

Can somebody please confirm the observed behaviour? If this is true, I guess we have to fix a bug in App-select.

@PPC are you around? Any idea?

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

[sybokMember]

Clear ‘./.cache/app-select’?

If it does not help, is there anything related in ‘~/.desktop-session/current.log’?
Does ‘app-select’ print something to STDOUT or STDERR when started from terminal?

[RobinMember]

sybok wrote:

Clear ‘./.cache/app-select’?

That is what I call a catch. Many thanks @Sybok!

Obviously this cache is only updated, if a .desktop file is removed completely or when a new file is added, but not when an existing file is upgraded merely.

So App-select won’t notice if a package updates its desktop file? That calls for a fix. Maybe creating a checksum could help here?

Proposal:
$ find -L . -type f -name "*.desktop" -exec md5sum {} + | LC_ALL=C sort | md5sum >~/.cache/app-select-state

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

[anti-apXosMember]

app-select does already compare the mtime of the applications directory to the cache to see if it needs to be updated. Your issue is probably caused by the symlinked desktop files thing I’ve been reading about. I’ve been wary about that because it seems likely to cause issues with a lot of apps and always just be pretty fragile. Isn’t there some other solution?

In this case, though, app-select could be changed to scan all the files in the applications directory and compare their individual mtimes to the cache. This follows symlinks by default.

Something like

cache_mtime = os.stat(cache_file).st_mtime
for desktop in os.scandir("/usr/share/applications"):
    if cache_mtime < desktop.stat().st_mtime:
        print("building or refreshing cache")
        text = open((cache_file), "w")
        text.close()
        break

It seems to work in my quick test and doesn’t really increase app-select’s startup perceptibly on my system.

"--"

[sybokMember]

Maybe creating a checksum could help here?

Probably; that’s safer than simple date check which can be messed up with simple ‘touch <filename>’.

But that would require app-select to check once the application is selected for any change of the cached file and to replace the record if such a change is detected (or append a new one and then always select the last match).
I guess it will still be faster than without caching and searching the ‘*.desktop’ file.

EDIT: App select can be called with a CLI option to refresh the cache; that’s probably what one should themselves do after such a manual change.

• This reply was modified 1 year, 2 months ago by sybok.

[RobinMember]

sybok wrote:

App select can be called with a CLI option to refresh the cache; that’s probably what one should themselves do after such a manual change.

Great! (Should really have checked its command line options first. Shame on me!)

anti-apXos wrote:

Your issue is probably caused by the symlinked desktop files thing I’ve been reading about.

Not in this case, since the desktop file in question was placed in the app folder directly, not a symlinked one.
But you are right, App-select should follow symlinks for this checking generally, since these are pretty common in Linux. It is perfectly fine with displaying the symlinked programs already.

anti-apXos wrote:

Isn’t there some other solution?

Not one I’d know of which could work as fast and reliable when refreshing the menu or installing new packages. Not relying on symlinks would mean to copy around hundreds of files again and again, creating true duplicates you can’t differentiate easily from files still stemming from the original packages. This would cause a huge mess in the end.

anti-apXos wrote:

app-select does already compare the mtime of the applications directory to the cache to see if it needs to be updated.

Most likely this value isn’t updated if modifying a file in an editor instead of putting a new one in its place? Then my issue would be an edge case merely: How many people are going to edit the exec line in an existing desktop file?

If you can confirm App-select treats .desktop files properly when they are updated via an package update from apt, then we can think whether we actually need to treat my edge case with manually editing a file, since there is the command line option for updating the cache. You just need to know it 🙂

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

[RobinMember]

I guess a really quick (and dirty) fix for this could be simply to add
app-select --refresh-cache
to the call which the “Refresh menu” entry executes, either directly, or even better, by integrating this call into desktop-menu –write-out-global.

Then not only the menu structure is updated when a new package is installed by apt or somebody presses “Refresh menu”, but always the same time when somebody refreshes the menu due to a modification in a .desktop file the app-select cache is refreshed. That feels naturally from user’s perspective, even if it is programmatically not the cleanest solution.

Comments?

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

[rokytnjiForum Admin]

I would have tested in JWM Bnd FluxBox session before moving the file.

Any problems with app-select in those Window managers?

Just asking.

Sometimes I drive a crooked road to get my mind straight.
I don't suffer from insanity. I enjoy every minute of it.
Motorcycle racing is rocket science.

Linux Registered User # 475019
How to Search for AntiX solutions to your problems

[anti-apXosMember]

Robin wrote:

Most likely this value isn’t updated if modifying a file in an editor instead of putting a new one in its place? Then my issue would be an edge case merely: How many people are going to edit the exec line in an existing desktop file?

I don’t know how many other people do, but I do it pretty often, especially the ones in ~/.local/share/applications. app-select always picks up these changes and rebuilds the cache the next time I open it. I just tested to be sure, including trying one in /usr/share/applications, and the cache was rebuilt.

I’m using v2.0.6, so maybe this is a bug introduced in 2.0.7?

"--"

[RobinMember]

rokytnji wrote:

I would have tested in JWM Bnd FluxBox session

If you are talking about the symlinks antix23 desktop-files creates: This has been fully tested on all WMs antiX comes with, before unleashing it on people.

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

[RobinMember]

anti-apXos wrote:

I’m using v2.0.6, so maybe this is a bug introduced in 2.0.7?

That’s really interesting, @anti-apXos. Unfortunately I can’t access the v2.0.6, apt gives me merely 2.0.7, so I can’t compare. Have you had a chance to compare the two versions for significant differences? From 2.0.7 you get definitively the behaviour I have described, I have just double-checked again: When changing the exec line in one of the .desktop files (not even one of the symlinked ones), e.g. by prepending the command with sudo or gksu, or by appending an ampersand for coprocessing it, using leafpad for the file edit directly in the /usr/share/applications folder, this change is not recognised by current app-select and it continues to use its privately cached version, even when in zzzFM the date/time of the .desktop file has changed. While when removing the desktop file completely and creating a new empty one with same name in its place, then copying over all the content, the cache is rebuilt, even when the content of the file has not been modified at all. Also when overwriting the file with a new version with another creation date the cache is not rebuilt, only when calling app-select with its –refresh-cache option this works reliable.

@Dave, you might want to have a look into this? Which of the possible fixes from above you’d prefer? I guess the one by @anti-apXos is the cleaner one. Or maybe you have your own idea how to deal with that? Can’t dive into this myself, since other tasks are pressing.

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

[marcelocripeMember]

AppSelect could also “learn” to read the “Keywords” entries from “.desktop” files that it is currently unable to read.

[marcelocripeMember]

Another issue is that we have several programs in the Control Center that cannot be found in AppSelect, because these programs do not have their “.desktop” files. My suggestion is to create the “.desktop” files that do not exist in order to increase the functionality of AppSelect.

If a user does not know where the program is in the Control Center and searches for it in AppSelect, they will certainly find it just by searching for a term related to the name or functionality of the respective program.

We would need to keep the “NoDisplay=True” option in these “.desktop” files to not display them in the menus as is done in “search-antix.desktop” and other “.desktop” files.

– – – – –

Uma outra questão, temos vários programas no Centro de Controle que não podem ser encontrados no AppSelect, porque estes programas não têm os seus arquivos “.desktop”. A minha sugestão é de criarmos os arquivos “.desktop” que não existem para aumentarmos as funcionalidades do AppSelect.

Se um usuário não sabe onde está o programa no Centro de Controle e procurar no AppSelect, certamente irá encontrá-lo apenas pesquisando por um termo relativo ao nome ou a funcionalidade do respectivo programa.

Precisaríamos manter a opção “NoDisplay=True” nestes arquivos “.desktop” para não exibi-los nos menus como é feito no “search-antix.desktop” e em outros arquivos “.desktop”.

[RobinMember]

marcelocripe wrote:

My suggestion is to create the “.desktop” files that do not exist in order to increase the functionality of AppSelect.

The tools currently packaged for the new entries antiX Hostname Cchanger and antiX Memory Manager already have included these .desktop files, and both of them have these NoDisplay=true lines. It is basically possible to create similar files for all the other tools behind the Control Centre entries.

But I have the question: If all these are in App-select, why would we need then a Control centre at all? I doubt that it is the best idea to have them there present. It’s just like with the antiX Main Menu. What is in Control Centre, should rather not turn up in Main menu nor in App-select, I believe. It’s all about having things in their proper places, rather than pile them up altogether in a huge heap where everything is present like Kraut und Rüben (That’s what App-select provides). But maybe I’m simply too much old-school, and hip people like this kind of rummage table atmosphere.

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

[Author]

Posts