Debian 10 / plasmashell 5.14.5

Please follow me in what appears to me a simple desktop use case in my initials interaction with a freshly installed system.
(putting icons on the desktop and changing some attibutes)

1. I create a new activity which by default in debian has Layout : Folder view.
(or using the existing desktop is we assume activities are a level more complex use case)

2. I drag and drop a menu entry (e.g: KCalc) on the desktop and i choose a LINK to be made.
(Q1. why in the Layout:Desktop i wont be asked when i drop an icon (copy|link|icon) ?)
(Q2. if i make a copy I notice that the icon will have a (!) on it until i execute it first. And a security dialog
will ask me if i trust the app. Why that happes with the COPY of the icon and not the LINK ? )

3. [terminal]
$ cd ~/Desktop
$ ls
lrwxrwxrwx 1 chomwitt chomwitt 45 Ιουλ 3 21:24 org.kde.kcalc.desktop -> /usr/share/applications/org.kde.kcalc.desktop


4. Desktop->Right click on new KCalc icon->Settings->(General tab)->change the text field KCalc to KCalc2 and click Ok.
( Q3: In the icon's settings General tab , that editable field is no named. What do we change here? )
A security warning will say that i cant change the icon settings.
The icon name on the desktop will remain KCalc. But as we see next the filename of the link will change.
(Q4: In the icon's / settings / Application tab there is a COMMENT and a DESCRIPTION field.
The description can be seen if a hover -but not on LINKS or COPIES only in the ADD ICON option (or choosing LAYOUT: Desktop)
But what's the use of the 'comment' field ?? )
If i do the same with rightclick-->rename then the icon name will change, the filenane of the link will change but not the unnamed field
in the icon's settings/general tab)

5. [terminal]
$ ls -al
lrwxrwxrwx 1 chomwitt chomwitt 45 Ιουλ 3 21:25 KCalc2.desktop -> /usr/share/applications/org.kde.kcalc.desktop

6. Now if again :
Desktop->Right click KCalc icon->Settings->(General tab)-> We see that
the unamed field has the KCalc value.

So from the result is as if that unamed field was used to change the filename of the Icon-LINK (the same happens with the icon-COPY too!) but not either the name of the icon or the name of the Settings/General/(appname?) field.

Also if i try to change icons's command line of the executable ,is not permitted. I assume because
the icon is a link and points to a file with root ownership. ( /usr/share/applications/)

So all that interaction (which was the same in debian 9) seems confusing and maybe a
grade more complex that would expect in my initial interaction.

But if i change the Layout to Desktop then things make more sense to me.
I can drop icons to the Desktop (i dont have options to select now for link|copy|icon ).
But know there is not editable entry with confusing semantics , and there is in the icon's settings/Application tab
a more clear editable field that can change the icons name.
The same (more clear and semanticaly simple ) behavior we get also if in the Folder layout we choose 'add icon'
when we drop an icon to the desktop.

(Q4: Also i dont understand the arguments %F, %U etc that i see in the command line of the icon's settings)

Alexandros

Q1 - because the Folder View layout displays the contents of the ~/Desktop location, including providing file manager like interactions, so dragging to such a desktop will offer options similar to dragging to the ~/Desktop folder in Dolphin; while the Desktop layout is a container for widgets only, so the only option is to create a shortcut icon widget.
Q2 - That is a little odd, though an explanation would be that the *.desktop files (in either /usr/share/applications or ~/.local/share/applications) don't need to be executable to show up and be "runnable" from the menus and other widgets. The .desktop file is really a shortcut to run some application (and you can create your own to run scripts or launch apps with custom command flags and such). Creating the copy creates a new shortcut file, and possibly the exclamation mark is just indicating that it detected a file which could be executable but isn't marked executable.

Q3 - you were changing the name (and properties) of the symlink file, not anything relating to the original .desktop file in /usr/share/applications. (the security warning may have been because it tried to change the name in the original .desktop file or something, but that requires root permissions which were not granted (or requested))
Q4 - the comment and description are primarily presented when displaying the application shortcut in the menus (and it looks like the Description field takes precedence over the Comment field). Again the Folder View layout presenting the contents of the ~/Desktop folder is likely just treating them as files as though you had Dolphin open to that folder rather than presenting them as application shortcuts.

Q4 (the second one) - those arguments indicate that the application can take a file or list of files as arguments. For example when you select one or more files and use Open With and select that application, it will invoke that application with the selected file(s) as arguments in place of the %F or %U (the difference between the two being that some applications may only open one file at a time or something).

Basically the differences you see are because the Folder View layout is presenting a view with a feel similar to a Dolphin window showing the ~/Desktop folder while the Desktop layout is only a container for widgets such as app launcher icons (among which you may add Folder View widgets to provide convenient access to the ~/Desktop or other folders at your choosing). A number of the differences are due to nuances between the handling of .desktop files vs. symbolic links vs. app launcher icons, which can be subtle and deceptive when you start exploring the details.

Q1: The Folder View is exactly that: a folder, same as if it were in a file manager. All copy and link functions will be identical to how it works using Dolphin.
Desktop view is more or less a place for widgets, so anything dragged there is not going to be an actual file.

As to the execute actions, my guess is that it as it is a link, you are interacting with a known executable in a known place directly, perhaps?
A copied .desktop file could theoretically be edited/modified to run something else unrelated. This confirmation can be disabled in Dolphin's settings, but it seems not to work on the Desktop, and I haven't found an option to disable it

airdrik wrote:Q1 - because the Folder View layout displays the contents of the ~/Desktop location, including providing file manager like interactions, so dragging to such a desktop will offer options similar to dragging to the ~/Desktop folder in Dolphin; while the Desktop layout is a container for widgets only, so the only option is to create a shortcut icon widget.

Indeed. The menus displayed when dropping a file to the Desktop(in folderview) is the same as in droping in dolphin with the added option to create a widget icon.

Q2 - That is a little odd, though an explanation would be that the *.desktop files (in either /usr/share/applications or ~/.local/share/applications) don't need to be executable to show up and be "runnable" from the menus and other widgets. The .desktop file is really a shortcut to run some application (and you can create your own to run scripts or launch apps with custom command flags and such). Creating the copy creates a new shortcut file, and possibly the exclamation mark is just indicating that it detected a file which could be executable but isn't marked executable.

You are right. In Desktop(folder view) the link created will not initially have 'x' permissions.

Q3 - you were changing the name (and properties) of the symlink file, not anything relating to the original .desktop file in /usr/share/applications. (the security warning may have been because it tried to change the name in the original .desktop file or something, but that requires root permissions which were not granted (or requested))

At that point the semantics (as you say in your footnote) are not clear. In dolphin , Icon settings/General tab/The editble field corresponds to the filename and of course you see that in the dolphin icon. To put in another way in dolphing there is a match between the filename and the icon's name. In the DESKTOP(folder view) that doesnt hold. Both with a link and a copy. The link/copy filename is changed but not the icon's name.
In the other hand 'RENAME' command from the LINK/COPY object menu honors that match.
So after clearing my head on this , i'd would say that the semantics on the editable field of the general tab of a link or copied icon on the DESKTOP(folder view) are not clear. You have folder view but the same object menu action works differently on dolphin from the DESKTOP(folder view).

Q4 - the comment and description are primarily presented when displaying the application shortcut in the menus (and it looks like the Description field takes precedence over the Comment field). Again the Folder View layout presenting the contents of the ~/Desktop folder is likely just treating them as files as though you had Dolphin open to that folder rather than presenting them as application shortcuts.

So the Comment field where will appear?

Q4 (the second one) - those arguments indicate that the application can take a file or list of files as arguments. For example when you select one or more files and use Open With and select that application, it will invoke that application with the selected file(s) as arguments in place of the %F or %U (the difference between the two being that some applications may only open one file at a time or something).

Thanks for that. totally unaware of the use case!

chomwitt wrote:
So the Comment field where will appear?

In the application menu for applications that show up there (primarily .desktop files in either /usr/share/applications or ~/.local/share/applications)