- This topic has 29 replies, 7 voices, and was last updated Jul 13-10:32 pm by Robin.
-
Posts
-
ile
.desktop; do lowercase t for true
NoDisplay=true
Dave
@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.
I will need to spend some time to look at this; but I do not see a problem with anti-apXos’s solution.
Computers are like air conditioners. They work fine until you start opening Windows. ~Author Unknown
Dave
https://gitlab.com/antiX-Dave/app-select-antix/-/commit/d1b419e38ba4213616484a883e47e8bdc3a2e95a
This should be updated now to update the cache file on a per item basis rather than a complete blanket rewrite.
Give it a try and make sure it works. I think it is a little better than discussed after looking at it.
If it works as expected a merge request will be sent.Computers are like air conditioners. They work fine until you start opening Windows. ~Author Unknown
Robin
If it works as expected a merge request will be sent.
Many thanks for the really quick fix, @Dave! App-select seems to notice now changed file content in .desktop files immediately after reopening. And still the cache is updated in a trice. On my 64 bit device with antiX 23.1 where I had chance already to test it, I don’t notice any delay opening the tool, when it then prints e.g. Updating cache for: /usr/share/applications/antiX-hostname-changer.desktop and Writing cache. Great.
Best would be if this could be confirmed by some other people who more heavily make use of this fine tool in their everyday workflow. For me it works fine.Windows is like a submarine. Open a window and serious problems will start.
@Dave Sorry, there are still some quirks with the cache. No clue what’s going on, but when adding more than a single file to the /usr/share/applications folder, sometimes I get the message:
$ python3 '/usr/local/bin/app-select' File "/usr/local/bin/app-select", line 626, in <module> win = mainWindow() ^^^^^^^^^^^^ File "/usr/local/bin/app-select", line 506, in __init__ self.fill_treeview() File "/usr/local/bin/app-select", line 322, in fill_treeview self.filtered_store = self.make_store() ^^^^^^^^^^^^^^^^^ File "/usr/local/bin/app-select", line 311, in make_store self.add_item(False, self.store, app, '') File "/usr/local/bin/app-select", line 222, in add_item cache_dict.pop(appfilename) KeyError: '/usr/share/applications/antiXCC-maintenance.desktop'App-Select won’t come up at all any longer after this. The files do work fine in antiX Main Menu and zzzFM, I can’t spot any issue with the key value pairs used in them.
When removing the decried file, the next one will be decried by App-selsect, and so on, until I have removed them all again.
This can be repeated. Also explicitly requesting --refresh-cache won’t work then:
$ python3 '/usr/local/bin/app-select' --refresh-cache Dateiname des Symbols nicht verfügbar Dateiname des Symbols nicht verfügbar Dateiname des Symbols nicht verfügbar Dateiname des Symbols nicht verfügbar Updating cache for: /usr/share/applications/antiXCC-hardware.desktop Traceback (most recent call last): File "/usr/local/bin/app-select", line 626, in <module> win = mainWindow() ^^^^^^^^^^^^ File "/usr/local/bin/app-select", line 506, in __init__ self.fill_treeview() File "/usr/local/bin/app-select", line 322, in fill_treeview self.filtered_store = self.make_store() ^^^^^^^^^^^^^^^^^ File "/usr/local/bin/app-select", line 311, in make_store self.add_item(False, self.store, app, '') File "/usr/local/bin/app-select", line 222, in add_item cache_dict.pop(appfilename) KeyError: '/usr/share/applications/antiXCC-hardware.desktop'The strange thing is: When after removing all files again from the folder, and once running app-select with --refresh-cache option again, now all the files can be added to the folder without getting the above errors. Doesn’t count whether I put them one by one in place or in one go. The files have been checked to be bit-identical to the copies used before, so this is not an issue with the files themselves, single possible conclusion is there must be something going wrong still in the cache generation or updating.
(Additional hint: The messages about “Dateiname des Symbols nicht verfügbar” don’t stem from the freshly added .desktop files, these result from some existing desktop files which obviously lack of the icon they try to use)
Windows is like a submarine. Open a window and serious problems will start.
Dave
Thanks Robin. I will try to resolve this later on. I am not sure why the app would be found in the cache dictionary and needing update but then not removable unless already removed. For clarification;
Does it happen when simply copying multiple items to the applications folder?
Do all the copied files have a common symbol in the name (- for instance)?
What were the file names you had tried moving?Computers are like air conditioners. They work fine until you start opening Windows. ~Author Unknown
Here you are them for testing (see attachment). Maybe you find some key or value error in them I have overlooked which could explain. Permissions for the files are rw-r--r--, same as for all the others already found there, owner is root when in place. (Note: To have them actually working you need the updated antixcc.sh file 1.2.9 which knows some command line options for direct tab access now.)
Does it happen when simply copying multiple items to the applications folder?
Yes. But two additional remarks. I’m pretty sure it first occurred after copying the antiXCC-desktop.desktop file to the applications folder, which was a single file merely. After this the error message repeats for each next added file or set of files. Once all of them were removed, and --refresh-cache was applied I can flawlessly add all of them, and then App-select updates its cache without that error message. Sometimes only a single file already is enough to cause the trouble. So I’m not completely convinced that it actually counts whether there are multiple new files or a single one.
Strange thing is that the very same files with the very same filenames and content are accepted later and work normally then in App-select, on a next try.
Do all the copied files have a common symbol in the name (- for instance)?
Yes, all of them have the slash. But many other files in the folder have the same slash in them e.g. rox-filer-as-root.desktop, repo-manager.desktop, root-editor.desktop and so on. Not sure whether these would act the same, difficult to check out once they are accepted by App-select. Moreover all my new files start with antiXCC. Above that, nothing special in the file name.
Windows is like a submarine. Open a window and serious problems will start.
Dave
Ok. I still have yet to look at this but from the additional information I would theorize that antixCC-desktop.desktop would get recognized after regex search of “.desktop” to antixCC. This would then match several other files and be removed from the dictionary leading to the keyword error.
When you added them separately was it possible that antiXCC-desktop.desktop was either first or last to be added?
Computers are like air conditioners. They work fine until you start opening Windows. ~Author Unknown
When you added them separately was it possible that antiXCC-desktop.desktop was either first or last to be added?
While antiXCC-desktop.desktop was actually the very first file which had caused the error when I had added it, later the order didn’t make any difference: They were rejected all, in whatever order until I called the --refresh-cache option after completely removing the failed ones from the folder.
But once accepted by App-select, sort order doesn’t any longer count, I can remove them, and then add them all in one go, or one by one, in arbitrary order. Then antiXCC-desktop.desktop is fine also as a first or last file. No complaints. Have still not found out what precisely triggers App-select at some point of time later to throw the error again when re-adding the files. The behaviour seems to me completely unpredictable. I guess one has to analyse the cache file, whether there something gets corrupted or changed when the error occurs. I have not deleted it manually for forced rebuild, that would be worth a try.
Interesting point is: Once accepted, their entries show up and work perfectly in App-select. Including antiXCC-desktop.desktop
Windows is like a submarine. Open a window and serious problems will start.
Dave
OK. Many thanks for the testing Robin.
This would have been a very bad bug if pushed out / merged. Any new .desktop file would have caused app-select to crash unless there was no existing cache file.
The original setup assumed that if the .desktop file was newer than the cache file an older entry would be in the cache. This is not true as a newly added .desktop file would be newer than the cache file but no older entry would exist in the cache file and therefor could not be removed (key error). I have also noticed when making this fix that the cache file could potentially grow forever as stale entries (where the matching .desktop file was removed) would not be removed from the cache.Here is the updated version for testing.
https://gitlab.com/antiX-Dave/app-select-antix/-/commit/d61b383fdd60128c709fa38371b46b1ddf240dcbComputers are like air conditioners. They work fine until you start opening Windows. ~Author Unknown
Seems like you have squashed it. Works like a charm already at first attempt. Many thanks, @Dave! That looks to me like you’ve had berserk work to spot the root cause for an erratic error behaviour like that. I would have thought some regex was the culprit, so it is really great you could narrow it down finally to the file dates and non existing entries.
$ app-select Updating cache for: /usr/share/applications/antiXCC-session.desktop Adding to cache: /usr/share/applications/antiXCC-session.desktop Updating cache for: /usr/share/applications/antiXCC-maintenance.desktop Adding to cache: /usr/share/applications/antiXCC-maintenance.desktop Updating cache for: /usr/share/applications/antiXCC-network.desktop Adding to cache: /usr/share/applications/antiXCC-network.desktop Updating cache for: /usr/share/applications/antiXCC-shares.desktop Adding to cache: /usr/share/applications/antiXCC-shares.desktop Updating cache for: /usr/share/applications/antiXCC-disks.desktop Adding to cache: /usr/share/applications/antiXCC-disks.desktop Updating cache for: /usr/share/applications/antiXCC-drivers.desktop Adding to cache: /usr/share/applications/antiXCC-drivers.desktop Updating cache for: /usr/share/applications/antiXCC-hardware.desktop Adding to cache: /usr/share/applications/antiXCC-hardware.desktop Updating cache for: /usr/share/applications/antiXCC-software.desktop Adding to cache: /usr/share/applications/antiXCC-software.desktop Updating cache for: /usr/share/applications/antiXCC-system.desktop Adding to cache: /usr/share/applications/antiXCC-system.desktop Updating cache for: /usr/share/applications/antiXCC-desktop.desktop Adding to cache: /usr/share/applications/antiXCC-desktop.desktop Updating cache for: /usr/share/applications/antiXCC-live.desktop Adding to cache: /usr/share/applications/antiXCC-live.desktop Writing cacheAllow me one more question. Is there a reason why in the GUI all headers of all entries are precisely repeated in parenthesis? (See screenshot) They read e.g.
Aktuelle Sitzung beenden (Aktuelle Sitzung beenden) USB-Geräte-Anschluß (USB-Geräte-Anschluß) antiX Computer Name Changer (antiX Computer Name Changer) antiX Memory Manager (antiX Memory Manager) Audioaufnahme - u. Bearbeitung (Audacity) (Audioaufnahme - u. Bearbeitung (Audacity)) ...There is not a single one which is not doubled, so this can’t stem from copied name to generic name entries within the files. I guess one could drop the 1:1 string copy in the parenthesis, maybe it is not meant to be there, at least it doesn’t make much sense.
Windows is like a submarine. Open a window and serious problems will start.
Dave
It is supposed to be [ name (generic name) ].
Seems that gio app info no longer shows different results for get_name and get_display_name. I think this used to correlate to name= and genericname=. Anyway it is now changed to use xdg.DesktopInfo to get the generic name.https://gitlab.com/antiX-Dave/app-select-antix/-/commit/ec4f61757181b1a967c80f840f321d449e4c257c
Computers are like air conditioners. They work fine until you start opening Windows. ~Author Unknown
latest change won’t let Appselect come up at all. Some python type-error.
$app-select Traceback (most recent call last): File "/usr/local/bin/app-select", line 47, in <module> if not os.path.isdir(config_dir): os.mkdir(config.dir) ^^^^^^^^^^ AttributeError: 'str' object has no attribute 'dir'Windows is like a submarine. Open a window and serious problems will start.
Dave
This typo should be fixed now.
Seems I merged the check for the config file location and naming from a newer version where there is a settings config and a plugins config.
~/.config/app-select.conf becomes ~/.config/app-select/plugins.conf
The typo was for making the ~/.config/app-select/ directory.
It also would have failed on the making of plugins.conf and settings.conf as they do not currently exist (outside of my test system). So this was also updated to use app-select.conf as plugins.conf and commented out the copy of settings.conf.Computers are like air conditioners. They work fine until you start opening Windows. ~Author Unknown
Works fine. (For me on antiX 23.1 full runit 64 bit live fully apt-upgraded.) Many thanks, @Dave. Others may do some more stress testing on it, I’m out of time due to the other construction areas, sorry.
Windows is like a submarine. Open a window and serious problems will start.
- You must be logged in to reply to this topic.