Names of desktop configuration files (.desktop) not accessible, breaking previously established workflow

changed the description

Sorry for the inconvenience. Though I dont plan to revert the commit and add a toggle setting to show the Application name for some reasons:

That would require additional code to be written, just for a very exotic special case.
When that possible special-setting "show desktop launcher name" is enabled, we would still need to take care for the bugs described in #56 (closed), since it would be possible again to trigger them.
I think your problem can be solved in a different, more simple way: How about renaming all your desktop files to the name of the related Application ?

Here a short script which should do the job for a folder. (Caution, best first comment the 'mv' line to see if it works fine for you/for all possible files, I did not test it properly.

#!/bin/bash
FILES=/path/to/desktop/files/*
for FILE in $FILES
do
  APP=$(less $FILE | grep ^Name= | awk -F"=" '{print $2}')
  NEW_FILE=$(echo $(dirname ${FILE})/${APP}.desktop)
  echo "Renaming $FILE to $NEW_FILE"
  mv ${FILE} ${NEW_FILE}
done

Edit: Probably some suffix parameter or numbering is needed if there are multiple .desktop files for the same application.

added 3. Need Info 5. Mime Types and .desktop Files labels

It is an extremely exotic case, so I understand. And thank you for taking the time to write up a demo script.

However, that script doesn't appear to solve anything on my end. If I'm reading your code correctly, it should produce something like this:

App1.desktop/(7) App.desktop
App2.desktop/(7) App.desktop
App3.desktop/(7) App.desktop
Cat1.desktop/(3) Cat.desktop
Cat2.desktop/(3) Cat.desktop
Cat3.desktop/(3) Cat.desktop
Exe1.desktop/(5) Exe.desktop
Exe2.desktop/(5) Exe.desktop
Exe3.desktop/(5) Exe.desktop

Which would transform my collection of .desktop entries into a collection of folders, each with a single .desktop entry within.

When, under the old behavior, Thunar would treat it like this:

(3) Cat
(3) Cat
(3) Cat
(5) Exe
(5) Exe
(5) Exe
(7) App
(7) App
(7) App

And if I were to increment the number:

(5) Exe
(5) Exe
(5) Exe
(7) App
(7) App
(7) App
(8) Cat
(8) Cat
(8) Cat

The way that my script currently works is that it edits the shortcut when I launch it. It checks another file for it's number and re-orients and shuffles itself according to the progress that I made, by editing the Name= parameter. The shortcuts have the same name because they point to the same application with different flags and inputs, and have individual icons to differentiate themselves.

It's a very non-standard use-case. Hopefully I did a better job of explaining it this time.

Just to make it perfectly clear, here's the relevant snippet of code that these .desktop files are running:

# Update Quote Totals On .Desktop Files
Q_NUM=0
for QUOTE in $(cat $QUOTE_FILE -E | grep "QUOTE: "); do
    if [[ $QUOTE == *"$"* ]]; then let Q_NUM++; fi
done
for LAUNCHER in $(find $LAUNCHER_DIR/$NAME*.desktop); do
    sed -i "2 c\Name=($Q_NUM) $NAME" "$LAUNCHER"
done

Renaming or moving the files in another way is an option I can explore, but moving the files each time I launch the .desktop file seems much less elegant than editing the Name= parameter.

So your script can do the renaming in your for loop already. Looks like you have the LAUNCHER file-Uri and the new name there. Note that you will need to suffix the filename with e.g. some incremental number to make the filename unique in case an application has multiple launchers.

Renaming or moving the files in another way is an option I can explore, but moving the files each time I launch the .desktop file seems much less elegant than editing the Name= parameter.

I think it would be a solid solution to move the files. Yes, it's an additional step, though would as well look clean on console, and is a magnitude less work than supporting name shadowing in thunar

closed

I would need to add a bit of additional code to prevent accidental file deletion, though.

One of the app names points to over 100 shortcuts. I doubt this is going to scale up well.

Plus the filenames being twice as long due to the .desktop extension is not exactly easy on the eyes.

An even easier alternative would be for me to switch to a file manager that has not removed this functionality.

I'd like to leave this issue open, as a feature request. As niche as my needs are, I know there's at least one other person who wants to see this behavior restored. It was brought to my attention from someone else's thread: https://old.reddit.com/r/archlinux/comments/kjtbg0/latest_thunar_update_seems_to_have_broken_desktop/

reopened

removed 3. Need Info label

It's not that niche @flameleaf, I also prefer the old way of displaying the Name for executable .desktop-files. But I also understand the implications. „explicit is better than implicit” is probably preferrable to prevent confusion.

What about a hidden option in Xfconf for the old behavior? I miss the old names too. In my case I don't save bookmarks within the browser but within disk folders. Over the years gathered almost 3000 of these web links and as you can imagine maybe having them stored in browser menus is less convenient with this size. Damn I guess I am spending too much time online ^^ But I also understand when the devs wouldn't accept a patch for a hidden setting because of code bloat. I also of course understand the security concerns and I respect that but if I am not mistaken these are still there on Xfdesktop because Xfdesktop still shows .desktop files in the old way. Also we should not forget we have now an inconsistency between Thunar and Xfdesktop which can be confusing too for users. So ladies and gentlemen what do you think about a hidden option in Xfsettings?

On Windows and I believe on MacOS too there are different file types for program starters and web links. On Windows we have the file types .url and .lnk. And I think that makes it easier for web links regarding security concerns. On Linux we have both features in one file which seems to make things more complicated because we always have to be care regarding security.

A web link is basically a program starter that executes the web browser with the target website as an argument.

Security is definitely something to consider, but I thought the old behavior worked well enough. Newly created or downloaded .desktop files would display the full filename. They only changed to displaying the Name= value if the user gave them executable permission.

Ok, fine, you got me. There seems to be a demand for this feature by multiple users. So here is, what I would support:

The xfconf settings needs to be opt-in. Default should be: "show real file names".
No support to rename the launcher name property via "rename". That was just super confusing. Instead show an item "modify launcher", like xfdesktop does. The dialog needs to be re-used in some way (no copy-paste from xfdesktop --> move to libxfce4ui ?).
Like before, "file->display_name" can be used to store the string of the Name-Property. But in addition we need a new thunar_file_get_name and use it over thunar_file_get_display_name wherever it makes sense, in order to prevent all the issues reported in #56 (closed). There is already thunar_file_get_basename for that purpose. It's just about using the correct method at the correct point in time.

Merge requests would be welcome !

So we then would have a new checkbox in the Thunar settings saying something like "Show real file names for launchers"? Have I understand you correctly?

IMO should be only in xfconf(xfce4-settings-editor), not in the thunar preferences.

This could be one way to do it but what do you think about the following idea? We could have a checkbox in Thunar settings which says "Show real file name for .desktop files". So when the box is checked it is clear what we do. We show the actual file name for all launchers. But when the box is unchecked we show the name property from within the file but only for .desktop files which are trusted ones via the gvfs sha256 checksum. And for the ones which aren't trusted we still show the actual file name.

This would have several benefits:

We would unify the appearance of .desktop files across Thunar and Xfdesktop and would cause less confusion among users
The setting is not hidden anymore and therefore easier to find
The security would not decrease because untrusted launchers still show the actual file name.

Now that we have trusted launchers via the checksum set in gvfs we could also improve the launchers for Xfdesktop because there is still the old behavior of launchers available meaning we show the name property from within the file even for untrusted launchers. So my proposal would be to show only the actual file name for untrusted launchers on Xfdesktop and for the trusted ones we show the name property from within the .desktop file.

So what do you think about that? Many thanks in advance.

Now that I think a bit more over it maybe there shouldn't be any setting at all and we should just make this what I described above the default behavior. The benefit would be then that we have no further clustering of the settings in Xfce.

Yes, that proposal sounds like a good solution which can be shared between thunar and xfdesktop !

check if sha256 checksum of launcher matches

yes --> show launcher name and icon
no --> show real name and default icon

Though I still think it would be good to have a xfconf setting to force real-names

Like always, merge requests are welcome !

I am working on this now. Two questions:

Would you like to have one or two separate patches. One for the xfconf setting and one for the correct display name?
Showing the correct display name is working quite good already but for now when one sets the gvfs flag via thunar_apr then the display name is not updated immediately. Instead one has to first press F5 to reload the view in Thunar. Can you get me a basic idea how to correct this? Do I have to send a signal from the Thunar APR plugin to Thunar or what? IPC needed? A certain class or function I can use? Stupid question?

Many thanks in advance for your help.

Would you like to have one or two separate patches. One for the xfconf setting and one for the correct display name?

Fine for me to have both together.

How to know that the gvfs flag changed ?

Phew, that is a good question. Maybe G_FILE_MONITOR_EVENT_ATTRIBUTE_CHANGED is triggered for the file via GFileMonitor on a metadata modification, though I am not sure on that .. to be tested.

Yeah I also got that idea with GFileMonitor. What I found out is that when I toggle the other checkbox "file is allowed to be started as .desktop file" in the same dialogue (thunar apr desktop page) then the icon refreshes immediately. Maybe that does now mean GFileMonitor cannot help us here but I am not sure...

By the way, we have no favicon set for https://developer.xfce.org/. Not a big thing but looks a bit weird when saved as a bookmark in Firefox.

Possibly G_FILE_MONITOR_EVENT_ATTRIBUTE_CHANGED is missing on one of our file monitors. It's just used once in thunar (Or possibly it does not matter at all, because the flag does not detect metadata changes at all) ... to be tested.

By the way, we have no favicon set for https://developer.xfce.org/. Not a big thing but looks a bit weird when saved as a bookmark in Firefox.

I suppose some running-mouse icon will do. Though dont know which project that website belongs to.

I took the freedom and also asked the guys over at Gnome and got a quite helpful response. So looks like I have to implement this via DBus.

Regarding the favicon we have the same icon for gitlab.xfce.org and www.xfce.org. Maybe we can use that. You mean Gitlab project? Maybe @lastonestanding can help us here?

By the way, we have no favicon set for https://developer.xfce.org/.

This is the faulty line: https://gitlab.xfce.org/xfce/xfce4-dev-tools/-/blob/master/apidocs/index.html#L5.

Thank you, so that's the location for the page. MR is online.

@alexxcons I have this working now but without listening to meta data changes which would require a workaround via dbus because GFileMonitor doesn't support meta data changes yet. This means the file name of a .desktop file doesn't get updated when somebody marks a .desktop file as secure/unsecure so the user needs to refresh the view of Thunar with F5. By the way, we already have this issue in the current Thunar version 4.18.6 when the user drag n drops an URL from Firefox into Thunar. So my question is would you still be happy to see a merge request without a meta data change listener? I am asking because I am not sure if I have the motivation, energy or brain to implement the listener via the dbus workaround.

Nice! Please go ahead and open a MR.

This means the file name of a .desktop file doesn't get updated when somebody marks a .desktop file as secure/unsecure so the user needs to refresh the view of Thunar with F5

Afaik that is already the case now, if only the trusted flag is changed ... so should be fine / is a different issue (I suppose we will need to trigger a redraw whenever the flag is set via the properties dialog)

In the properties menu of the .desktop files we now have two checkboxes which have the same function:

Allow file to be executed as program (file permissions tab)
File is allowed to be launched as .desktop file (launcher tab)

I wonder if we could remove one? For example we could remove the checkbox on the launcher tab and move the checkbox "Mark this file as trusted" to the permissions tab. I mean we have duplicate widgets here and I asked myself if this is really necessary. So what do you think?

That's a different story. Please open a separate bug for it to discuss it there. So far the trusted flag is only for launchers. Not sure if it makes sense to as well use it for executables.

mentioned in issue #768 (closed)

mentioned in issue #1021 (closed)

added 2. Enhancement label

mentioned in merge request !354 (merged)

mentioned in commit 6cd1a330

changed milestone to %4.19.0

Fixed by !354 (merged) thanks to @dc_coder_84, to be released in 4.19.0

closed

mentioned in issue #1174

mentioned in issue #1524 (closed)

Names of desktop configuration files (.desktop) not accessible, breaking previously established workflow

Designs

Child items 0

Activity