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.
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.
What about just adding a confirmation dialog, or making the panel only accept drops when the 'add new item' dialog is open?
Oops. My suggestion won't help accidentally dragging inside the menu itself. Maybe only allow menu dragging with an alternate button?
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...
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.
(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.
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 deed seem sloppy and inconsistent to me. Furthermore: ***** When removing one of the icons, without the add-item-window open (i.e. no greyed out panels) a confirmation-dialog appears. This is a good thing, but: it doesn't contain the title of the launcher, but only the title 'launcher'. This wouldn't be such a problem if: (1) the visual cue for selection (gradient+bezel around icon) would remain after opening the context menu on the icon, and (2) the panel would specifically remain visible (as there is an action being performed on it) instead of hidden, even though it is set to auto-hide. (This does happen correctly after opening the add-item-window!) -- I am really happy with my xfce, and am thinking about upgrading to 4.6, but -aiming for a perfect experience- will be nit-picking for more usability-polish indefinitely :)
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.
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.
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.
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.
*** Bug 6756 has been marked as a duplicate of this bug. ***
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.
Now you can create a launcher by drag and drom from the desktop to the panel. (since 4.10 or 4.12 ?)