Summary: | [PATCH] missing "add application to panel" (regression) | ||
---|---|---|---|
Product: | [Plasma] plasma4 | Reporter: | Maciej Pilichowski <bluedzins> |
Component: | general | Assignee: | Will Stephenson <wstephenson> |
Status: | RESOLVED FIXED | ||
Severity: | wishlist | CC: | goldstein.mark, mueller, plasma-bugs, sven.burmeister, wstephenson |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Ubuntu | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: | implement described fix |
Description
Maciej Pilichowski
2008-06-11 22:25:08 UTC
"Add application" will not be making it back as it is far too desktop centric. I assume that in 4.2 we'll offer a specialization of the Icon applet that provides a way to pick an Application from the menu. in the meantime, just drag items from menu (or right click on them) to get application launchers. Yes, I noticed D&D but not that while this mechanism is very cool it is a killer for any handicapped person. Please note there is now _no_ way to add application to the panel that is user-friendly for people with even mild disabilities (like even age, i.e. older people). kickoff is fully keyboard navigable, and you can pull up context menus without using the mouse. if you wish to complain about a11y, talk about real issues how we can't assign keyboard focus to a panel in kwin (something we're fixing in 4.2) ;) in any case, i believe i was agreeing with you that we should have an "Application" widget in the add widgets list. I use Kmenu because Kickoff is again seriously flawed (by design) in a11y (nice shortcut :-) ) terms. > if you wish to complain about a11y, talk about real issues how we can't > assign keyboard focus to a panel in kwin (something we're fixing in 4.2) ;) I am not sure what it means (in KDE4) but AFAIR I sent similar report some time ago even for KDE3. > we should have an "Application" widget in the add widgets list. I'll wait for 4.2, because I cannot tell what the effect of this widget will be, but till then I keep testing 4.x and sending reports. >in the meantime, just drag items from menu
> (or right click on them) to get application launchers.
As a note, I am not able to drag and drop from the menu to the panel, in 4.1.3. I can drop it on the Desktop - but not on the panel. And Kmenuedit says it puts things in the system tray, but that setting only works for that session.
Right-clicking an item on the menu launches it, same way a left-click works.
Is that the way it's supposed to work?
Add new panel, completely new, drag&drop from KMenu any app and drop it over the panel. KDE4.1.3. The problem you see is probably not enough visual indication where you drop app in crowded panel. *** Bug 169522 has been marked as a duplicate of this bug. *** The opensuse@opensuse.org users' list also ran into this, adding a non-menu application to the panel is just possible by dragging a binary from /usr/bin/ in a file manager to the panel, but since the URL for this Icon is file:///path/to/binary the Icon cannot be edited, for example its icon can't be changed without messing with the mimetype's icon. The workaround is to create a menu entry with kmenuedit, creating a .desktop file, then drag that to the panel. I propose cutting out the kmenuedit step, by having Icon create a .desktop file in .local/share/applications for the dropped URL. Is this ok? If so I'll implement it. And what's the reason Icon is not shown in the Add Widgets UI? Will would it be possible to add one level to this directory, something like this: .local/share/applications/dynamic or .local/share/applications/temporary The reason: indication the entries made on-fly, not explictly. Created attachment 38922 [details]
implement described fix
Creates a desktop file when an Icon is instantiated for a local executable path and sets the URL to that of the desktop file, allowing the user to customise the appearance of the Icon.
Maciej, I don't see a significant difference between user-specific desktop files created by making an Icon, files created by hand, and created by making a menu item in kmenuedit, they are all permanent and 'explicitly' created by user action and will contain user customisations that are of value. Therefore I don't think there needs to be a separate subdirectory for these icons.
Additionally, there is already a nice kdelibs function for obtaining a unique filename for a new desktop file (KService::newServicePath()) and adding more subdirectories onto this path would require rewriting this.
Git commit da7c62519af9c641ed92a462ef3deacb202deac7 by Aaron Seigo. Committed on 02/12/2011 at 12:02. Pushed by aseigo into branch 'master'. if it is a binary, then make a desktop file for it patch by Will Stephenson BUG:163831 M +27 -1 plasma/generic/applets/icon/icon.cpp http://commits.kde.org/kde-workspace/da7c62519af9c641ed92a462ef3deacb202deac7 |