! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
Dragging files to the desktop should create .desktop files
Status:
RESOLVED: LATER
Severity:
enhancement
Product:
Xfdesktop
Component:
General

Comments

Description herd 2006-05-16 16:58:19 CEST
Enhancement request as seen from 4.3.90.1 with desktop icons enabled

When I drag a file from Thunar or Nautilus to the xfce desktop, I'd expect:
- a move with shift left drag
- a copy with ctrl left drag
- a symlink with ctrl+shift left drag. 

As of 4.3.90.1, I can only do a copy atm, see (resolved) bug 1788.

IMHO, it would be a good idea to:
a) not create a symlink but a .desktop file instead.
b) enhance the desktop context menu so that a paste (file/file.desktop) can be accomplished.
Comment 1 Brian J. Tarricone (not reading bugmail) 2006-05-16 17:25:38 CEST
(In reply to comment #0)
> Enhancement request as seen from 4.3.90.1 with desktop icons enabled
> 
> When I drag a file from Thunar or Nautilus to the xfce desktop, I'd expect:
> - a move with shift left drag
> - a copy with ctrl left drag
> - a symlink with ctrl+shift left drag.

xfdesktop works the same way Thunar does:
* Copy with drag
* Move with shift+drag
* Link with ctrl+shift+drag

> As of 4.3.90.1, I can only do a copy atm, see (resolved) bug 1788.

xfdesktop does not and will not support right-drag

> IMHO, it would be a good idea to:
> a) not create a symlink but a .desktop file instead.

Why?

> b) enhance the desktop context menu so that a paste (file/file.desktop) can be
> accomplished.

Probably not going to happen.
Comment 2 herd 2006-05-16 20:41:26 CEST
Sorry I just confirmed that Ctrl+Shift dragging from nautilus works but from thunar 0.3.0 beta 1 works only if you did not press Ctrl+Shift before dragging.

The advantage of creating a launcher instead of a symlink would be the customizability, e.g. applying custom icons. Having all the features of a launcher without manually porting them to a link property sheet seems a bonus, too.

As for the desktop context menu, adding 'Create new folder' and 'Create new Launcher' menu items should be easier to implement/package than 'Paste launcher'. This would provide more consistency with the panel, IMHO.

Another use-case of the desktop context menu would be non-mousing usage:
Imagine you are sitting in a train, the laptop on your knees and you want to paste something on your desktop. The touchpad is only a blunt instrument unless you want to constantly elbow your neighbor. What would you do? Select the file with the arrow keys, hit Ctrl+C, switch to the desktop with some custom keystroke and hit Ctrl+V for a copy, Ctrl+Shift+V for a symlink? I wish I could do that. I'd modify my desktop context menu to include some script that symlinks the contents of the clipboard, but it is ignoring the context menu key / Ctrl+Enter anyway...

I regard nautilus rendering the desktop to be a major nuisance in gnome while in contrast xfdesktop and thunar being separate apps in xfce4 to be a major plus. Nevertheless, if the desktop shows icons, a consistent handling of both context menus (including keystrokes) should improve usability in terms of interoperability, IMHO.
Comment 3 Brian J. Tarricone (not reading bugmail) 2006-05-17 09:07:51 CEST
(In reply to comment #2)
> Sorry I just confirmed that Ctrl+Shift dragging from nautilus works but from
> thunar 0.3.0 beta 1 works only if you did not press Ctrl+Shift before dragging.

Works fine here.  I'm using current Thunar and xfdesktop SVN.

> The advantage of creating a launcher instead of a symlink would be the
> customizability, e.g. applying custom icons. Having all the features of a
> launcher without manually porting them to a link property sheet seems a bonus,
> too.

Perhaps, but it's non-standard and not expected behavior.  I'm also certainly not changing it for xfdesktop unless Thunar does it too.

> As for the desktop context menu, adding 'Create new folder' and 'Create new
> Launcher' menu items should be easier to implement/package than 'Paste
> launcher'. This would provide more consistency with the panel, IMHO.

Sorry, I don't really understand what you mean here.  The context menu already has 'create new folder' and 'create new launcher'.

> Another use-case of the desktop context menu would be non-mousing usage:
> Imagine you are sitting in a train, the laptop on your knees and you want to
> paste something on your desktop. The touchpad is only a blunt instrument unless
> you want to constantly elbow your neighbor.

Really?  I can use my touchpad without moving my arm at all (just moving my finger).

> What would you do?

I'd not use a GUI element that is designed against a metaphor that requires a mouse.

> Select the file
> with the arrow keys, hit Ctrl+C, switch to the desktop with some custom
> keystroke and hit Ctrl+V for a copy, Ctrl+Shift+V for a symlink? I wish I could
> do that. I'd modify my desktop context menu to include some script that
> symlinks the contents of the clipboard, but it is ignoring the context menu key
> / Ctrl+Enter anyway...
> 
> I regard nautilus rendering the desktop to be a major nuisance in gnome while
> in contrast xfdesktop and thunar being separate apps in xfce4 to be a major
> plus. Nevertheless, if the desktop shows icons, a consistent handling of both
> context menus (including keystrokes) should improve usability in terms of
> interoperability, IMHO.

Well, the problem here is trying to be compatible with the desktop menu.  Clicking on a blank area of the desktop should bring up the desktop menu, which is user-editable.  I'm not going to forcibly add stuff to it.  Also, the desktop menu has no knowledge of the icon view, and the icon view doesn't know about the desktop menu.  This is not going to change.

I've been debating adding back the paste support, but I dislike the UI for it.  I already dislike how the 'Create folder/launcher/file' menu item is on the icon context menu, since you'd expect items in the icon context menu to act on that particular icon.  So you'd think that 'Create folder' when right-clicking on a folder would actually create a folder inside the folder you clicked on, not the desktop.  Adding 'Paste' to that menu sounds ambiguous.  Paste to the desktop?  Paste in the folder that's selected?  Run the selected icon passing the paste data as the first argument?

Anyway, please file a separate enhancement request for the paste functionality.  One bug per report.
Comment 4 herd 2006-05-17 18:14:26 CEST
Hello again,

When I said context menu, I was referring to the desktop menu (in my synopsis, it is the context menu of the desktop folder rendered by the icon view). Are you saying that you would not expect to right click on the desktop in icon view mode, and having 'Create Launcher' and 'Create Folder' appear on the desktop menu? 

If I understood you correctly, right clicking on an icon that is already on the desktop to create another one sounds so strange to me that I probably missed its existence altogether. 

Drag/drop and copy/paste (keyboard and context menu) tend to always come together - I don't see why it should be different on the desktop.

I'll build from svn and check what I have learned, thanks very much so far. 
Still, I doubt the separation of desktop menu and icon view will remain carved in marble forever ;)

To put some clarity in:
I tend to use the desktop as a parking lot for shortcuts to improve my productivity and eagerly awaited desktop icons to happen in xfce. I think I found an inconsistency in drag/drop copy/paste functionality between two thunar instances and in contrast between thunar and the desktop: As I heard that xfdesktop reuses a thunar plugin to draw the icons, I automatically assumed that the interaction between the two would be exactly the same as between two thunar instances. I stand corrected.

I guess that creating a launcher with drag/drop or edit/paste from thunar to xfdesktop is off the shelf for now and some time to come, so if you agree, I'll postpone this enhancement request.
Comment 5 Brian J. Tarricone (not reading bugmail) 2006-05-17 21:05:35 CEST
(In reply to comment #4)
> Hello again,
> 
> When I said context menu, I was referring to the desktop menu (in my synopsis,
> it is the context menu of the desktop folder rendered by the icon view).

How I refer to things:
* "the desktop menu": the menu that pops up when you right-click on the desktop, NOT on an icon.  It's the user-configurable applications menu that can be edited via xfce4-menueditor.
* "icon context menu", or simply "context menu": the menu that pops up when you right-click on an icon sitting on the desktop (open, cut, copy, rename, properties, etc.)

> Are
> you saying that you would not expect to right click on the desktop in icon view
> mode, and having 'Create Launcher' and 'Create Folder' appear on the desktop
> menu? 

No, the opposite.  I'm saying that the 'create...' items should NOT be in the icon context menu, but on the desktop menu proper.  However, that just plain doesn't work with how the desktop menu works, and I don't see a way to reconcile those differences without removing the desktop menu entirely when in icon view mode, and replacing it with something else.  Which is an option, I suppose, though one I know people will complain about.

> If I understood you correctly, right clicking on an icon that is already on the
> desktop to create another one sounds so strange to me that I probably missed
> its existence altogether.

Exactly.  It just doesn't make logical sense, but that's the only way I've seen to implement it without introducing nasty dependencies between the icon view and the desktop menu.
 
> Drag/drop and copy/paste (keyboard and context menu) tend to always come
> together - I don't see why it should be different on the desktop.

It's not, except for the lack of 'paste' ability, which I'm more or less convinced should be added, even if it's unintuitive to put it in the icon context menu.

> I'll build from svn and check what I have learned, thanks very much so far. 
> Still, I doubt the separation of desktop menu and icon view will remain carved
> in marble forever ;)

Doubt all you want, but I have no plans on integrating the two, unless there's a way to do it without needing the desktop menu to know anything about the icon view.  I do have a couple ideas there, but they're not going to be for 4.4.  For 4.6, Thunar will likely handle drawing the desktop, so it may be a moot point.

> To put some clarity in:
> I tend to use the desktop as a parking lot for shortcuts to improve my
> productivity and eagerly awaited desktop icons to happen in xfce. I think I
> found an inconsistency in drag/drop copy/paste functionality between two thunar
> instances and in contrast between thunar and the desktop: As I heard that
> xfdesktop reuses a thunar plugin to draw the icons, I automatically assumed
> that the interaction between the two would be exactly the same as between two
> thunar instances. I stand corrected.

Xfdesktop does not use a thunar plugin to draw the icons.  It uses thunar's VFS library for accessing the files themselves, and can support plugins that do things like add entries to the icon context menu, or add properties pages to the icon properties dialog.

> I guess that creating a launcher with drag/drop or edit/paste from thunar to
> xfdesktop is off the shelf for now and some time to come, so if you agree, I'll
> postpone this enhancement request.

Yes, I don't think creating a launcher from a drag is going to happen.  I would consider adding the 'paste' functionality; feel free to create another enhancement request for that.
Comment 6 herd 2006-05-18 10:51:49 CEST
Enhancement request has been postponed to a later version.
(To reappear when and if Thunar manages the desktop)

Bug #1818

Reported by:
herd
Reported on: 2006-05-16
Last modified on: 2009-07-14

People

Assignee:
Brian J. Tarricone (not reading bugmail)
CC List:
1 user

Version

Attachments

Additional information