Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Drag and drop from System Settings fails|
|Product:||[Fedora] Fedora||Reporter:||Need Real Name <lsof>|
|Component:||gnome-terminal||Assignee:||Ray Strode [halfline] <rstrode>|
|Status:||CLOSED WONTFIX||QA Contact:||David Lawrence <dkl>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2004-11-05 14:43:19 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Need Real Name 2004-04-01 18:00:28 EST
Description of problem: I cannot drag and drop icons from System Settings to a terminal. I want to do this since double-clicking "Bootloader" as non-root does not load anything, nor does an error show. I tried dragging the icon onto a root terminal, but get the shortcut: system-settings:///redhat.. This does not work, maybe it should..
Comment 1 Harald Hoyer 2004-04-02 02:33:14 EST
it will show: system-settings:///redhat-system-config-boot.desktop which refers to: /usr/share/applications/redhat-system-config-boot.desktop which will execute: Exec=/usr/bin/system-config-boot which is linked with the consolehelper, which then should execute: /usr/sbin/system-config-boot since this does not work, I reassign to usermode $ rpm -qf /usr/bin/consolehelper usermode-1.69-5
Comment 2 Jindrich Novy 2004-09-21 09:19:04 EDT
I think this has nothing important to do with usermode. IMHO the better solution would be to reassign this to gnome-terminal in order to deal with drag-and-drop action on root terminal correctly. In my case (FC2) it shows: applications:/System Settings/system-config-boot.desktop and therefore it should call consolehelper Personaly I think that to open a root terminal and write system-config-boot is better than such mouseclicking ;-)
Comment 3 Ray Strode [halfline] 2004-11-05 14:43:19 EST
The root of this bug is the user wants to be able to easily start system-config-boot using an unprivileged account. He should be able to do this by double-clicking it. This should prompt him for the root password and then run it. As far as I can tell it does this fine, so the user may have had a messed up configuration locally. Dragging the icon to the terminal isn't going to work because it's not designed to work that way. Nautilus will send applications that receive a dropped icon a uri pointing to the location of where the file the icon represents is located. In this case the icon is a .desktop file, so the uri given is a .desktop file. That seems like reasonable behavior to me. The alternative would be to have the terminal widget check if the uri handed to it was a .desktop file, open and parse the .desktop file, extract the Exec line and subtitute the location of the executable instead of the .desktop file. That's a lot of special casing that isn't really a terminal widget's job. Simon, I'm going to close this bug WONTFIX, but if double-clicking doesn't work for you then it would be good if you could open a new bug describing the problem.
Comment 4 Need Real Name 2004-11-05 14:47:51 EST
> The root of this bug is the user wants to be able to easily start > system-config-boot using an unprivileged account. The root of the bug is that people expect a drag and drop to do whatever they expect :/
Comment 5 Ray Strode [halfline] 2004-11-05 15:10:03 EST
The problem is there is no way to know what the user expects. Does the user want the actual .desktop file or does the user want the program the desktop file references? There are other concerns, too. What if icon is being dropped from over the network? Should the terminal widget go out on to the network, download the .desktop file, parse it and extract the exec line? Why should it special case .desktop files and not other files?
Comment 6 Need Real Name 2004-11-05 15:13:31 EST
> The problem is there is no way to know what the user expects That's my point. Since the uri for this drag-and-dropped icon isn't useful, perhaps the best idea would for icons dragged from the panel to display nothing when dragged onto gnome-terminal.. I expect that means a horrible hack though :/