No easy way to create launchers on panel or desktop

[Daniel Dickinson]

Creating desktop or panel launchers is not user friendly for new users. I'm okay because I've used debian and have gone through the package list a few times so I have a good idea of what the executable's name is for a given menu entry, and I know where to find the icons (/usr/share/{icons|pixmaps} or application dir), but a new user is SOL.

Ideally one could right-click on a menu and create a launcher in the desired location, or the create launcher window could let one browse the menu (not just the menu file though because most menu items are part of includes that aren't in the menu file) and select the application of choice.

[Nyutwo (nyutwo)]

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.1) Gecko/20060601 Firefox/2.0.0.1 (Ubuntu-edgy)
Build Identifier:

When adding something to a panel, it would be rather convenient if I could just drag something from my menu, and have the launcher created using the same information that the menu uses. Perhaps something like a 'create launcher from menu' option?

Reproducible: Always

Steps to Reproduce:
Just try to add anything that is in the menu to a panel. There is no really intuitive way, as far as I know.

[Brian Tarricone (kelnos)]

Sometime pre-4.2, I actually had the menu set up so items could be draggable. We never got around to implementing the drop part on the panel, and found that people very easily triggered the drag on the menu by accident, which was confusing and annoying. I'll leave this open in case anyone else wants to comment, but this might not be the best idea.

Maybe I could artificially double the drag threshold just for those menu items...? Not sure.

[Nyutwo (nyutwo)]

What about just adding a confirmation dialog, or making the panel only accept drops when the 'add new item' dialog is open?

[Nyutwo (nyutwo)]

Oops. My suggestion won't help accidentally dragging inside the menu itself.

Maybe only allow menu dragging with an alternate button?

[Brian Tarricone (kelnos)]

An alternate button is a decent idea to avoid accidental dragging, but it's not very self-documenting; i.e., it behaves differently from what a user would expect. Another option would be a key combo - hold down ctrl and drag, or something like that, but that has the same problem.

Not saying either is inherently bad, but...

[Nyutwo (nyutwo)]

It behaves the same as, say, middle-clicking on a window frame to drag it around. Not a lot of people do that, I guess, but the behavoir is there already.

[Brian Tarricone (kelnos)]

(In reply to comment #5)
> It behaves the same as, say, middle-clicking on a window frame to drag it
> around. Not a lot of people do that, I guess, but the behavoir is there
> already.

No, that's completely different; that's WM behavior, and aside from some specs on how to do things with managing the windows, there's no real "normal" way to click on the windows and move them around.

By contrast, DnD is implemented by Gtk in such a way that using an alternate button or a key-combo is unintuitive and unexpected.

[Jérôme Guelfucci (jerome-guelfucci-deactivatedaccount)]

Thank you for your bug report. I forwarded this upstream.

[Jérôme Guelfucci (jerome-guelfucci-deactivatedaccount)]

Fix committed upstream.

[Sam Besselink (sambesselink)]

DISCLAIMER: I'm using xfce 4.4.3 and am afraid I'm a serious nit-picker.

I concur this is a semi-serious usability problem. But from a usability perspective it will only be process enhancement, as there already is a way to do it. (Researching this, though, made me find some usability _bugs_. O Tao!)

To illustrate how this is a lengthy process, I will also describe user-specific stuff. I'll be using my config, please feel free to comment on its efficiency!

The HCI-procedure is based on two sub-procedures and the subsequent integration of their end results:

- Opening the appfinder application;
[The steps to perform this will be user-configuration specific!]
a) Opening the desktopmenu (either by finding free desktopspace, or by finding the menu button on my panel, which is autohidden :/ ),
b) opening my 'settings'-menu, and subsequently firing the appfinder launcher.

- Opening the 'add launcher'-window;
a) Get the context-menu of the panel to open up,
b) from the context-menu, choose "add new item",
c) from the available items, choose "launcher".

- Integrating the processes;
a) Drag an item from the appfinder into one of two areas of the launcher window:
i The queu of launcher-items* (used for creating launcher-menus -- same area as where normally your 'favourite folders' are located), or
ii the area which contains all parameters of the created** launcher and their values.

As you see this is quite a bloated and clumsy process. Nonetheless, I consider this a usability enhancement, not a bug.

Here's a bunch of usability bugs I found:

* When dragging a .desktop entry from the appfinder into the queu of the launcher window, there is no visual cue as to the effect of dropping! This does happen when adding a folder to the 'favourite folders' area, which seems to be an HCI-synonym.

** After having dropped the .desktop entry from the appfinder into the launcher queu, the width of the queu-area will automagically be increased if the title of the .desktop entry doesn't fit. After the entry has been removed from the queu, the width isn't being automagically reduced. This should happen in order to stay consequent to own (implied) usability principles. (Automagic increase after a change to some state, should definitively automagically decrease after a change back to the previous state! It does return to default width after closing and opening the window, though.)

*** But closing and opening the launcher window triggers another usability bug: There is no way to cancel the action of adding a launcher! There's no cancel button, and the minus (for removing entries from the queu) is greyed out..
Everytime the launcher window is opened from the item-selection-window xfce adds an icon to the panel. Now it seems we have to go all the way back in order to remove the icon from the panel, and we run into *another* couple of usability bugs:

**** Although it seemed to me I couldn't remove the launcher-icons from the panel with my add-panel-item menu open -since all of it (besides the volumebar from my volume-control-item) was greyed out- the context menu for the items did open! Although in general it is a good thing that functionality wasn't reduced, it de...

[Brian Tarricone (kelnos)]

Sam: please don't hijack bugs. This is about one thing and one thing only: being able to drag menu items.

Regardless, this sort of discussion is not appropriate for bugzilla (especially since many of your comments touch on components owned by other people). You should take this to the xfce4-dev mailing list.

[Jeromeg (jeromeg)]

We should add drag and drop support for the right click menu items as we did for the menu panel plugin, for the sake of consistency.

Marking this as a 4.8 blocker as agreed with Jannis and Nick a while ago.

[8-nick (8-nick)]

I looked at this, but because we need to fix a lot in the application menu code (so it is not destroyed all the time, which conflicts a lot with the current menu implementation), the changes are too big for after pre1.

It's on the 4.10 todo list, dropped the block flag.

[Charlie Kravetz (cjkgeek)]

Xfce4.8 allows you to open /usr/share/applications, right-click the file desired, highlight "Open with...", and create the launcher on the panel.

[Charlie Kravetz (cjkgeek)]

In Xfce4.8, I can open /usr/share/applications, click on "Open with... ", and create a launcher on the panel. That allows creating the launcher matching the menu item.

[upkpk (upkpk)]

*** Bug 6756 has been marked as a duplicate of this bug. ***

[KitchM (tech-frontrowcomputer)]

A couple mistakes. First, this did indeed include menus and desktop icons. Second, the implication from "menus" is context menus too. Third, I wish to see the automount icons for removable media to be custom placeable. This could allow the functions to follow the icon and the icon to appear where desired automatically.

I also noted that there was some confusion about accidental menu item movement/deletion. This has been a usability flaw in various designs. Unless one selects a left-click context menu item, the original menu item cannot be allowed to be deleted, even if dragged to create a new icon. It is a simple programming flaw that cannot be allowed. When this happens the intuitive nature of a GUI is lost.