Re: Review Request: Device notifier: show mounted device and path
On Friday 12 October 2012 15:56:18 Sebastian Kügler wrote: On Friday, October 12, 2012 13:42:35 Lamarque Vieira Souza wrote: This tooltip looks really odd and out of place this way.:/ The transparency effect does not look good here. I would like to know how to disable it too, there is this bug against the QML shutdown dialog with the same problem: https://bugs.kde.org/show_bug.cgi?id=303934 No, I'm not talking about the translucency, I'm talking about having a tooltip on top of a popup, that's weird (and IMO a showstopper). Well, the notifier already shows several tooltips as it is now. - one appearing when hovering over the device icon - one appearing when hovering over the mount/unmount action - one appearing when hovering over the capacity bar People were complaining about icons not being informative enough, hence we had to add tooltips here and there :/ Any suggestion to improve the current state is most welcome :) __J
Re: Review Request: Device notifier: show mounted device and path
On Oct. 8, 2012, 9:52 a.m., Aaron J. Seigo wrote: any application which expects the user to access files on disk but does not provide a clear representation of mounted / removable devices is broken. there's no point in degrading our own primary UI for such fixable brokenness. can you provide a (short :) list of any such broken applications which are high-profile / in common use? Aaron J. Seigo wrote: ah, and i should also add that tooltips on items in popup windows as it leads to a matryoshka doll effect that is most inelegant visually, so we try to avoid such things unless there is a very good reason for them. Jonathan Marten wrote: I think too that nested popups/tooltips look inelegant, but since it was Jacopo's suggestion I though it may be at least worth trying it out... In my experience hardly any non-KDE applications are able to show or control the mounting of removable devices - most of them stick to the hopeless Gnome file selector, and not all of them can be made to work well with KDE integration. Certainly in my daily use neither mozilla, libreoffice/openoffice, gimp or googleearth identify removable devices. Inkscape is the only major application that at least tries. They are indeed broken (by design), but they are unlikely to be fixed before the heat death of the universe. My point was rather to stuff that information in some --already present-- tooltip, such as the one appearing hovering over the capacity bar or the device icon. But yes this is indeed still visually unpleasant. Besides, I agree with Aaron about creating some “Technical info” pane with all this information, which could be triggered by context menu. I do not want to clutter the ui any further. It's already pretty full. Cheers - Jacopo De --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106755/#review20057 --- On Oct. 8, 2012, 9:31 a.m., Jonathan Marten wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106755/ --- (Updated Oct. 8, 2012, 9:31 a.m.) Review request for KDE Base Apps and Plasma. Description --- If a removable device is mounted using the Plasma device notifier, there is no indication of what the Unix name of the device is or where it is mounted. This information may be useful to the user for (a) accessing the mounted device from non-KDE applications, or (b) troubleshooting mounting or unmounting problems. The attached patch shows this information when the device is hovered over, just above the N actions for this device text. Depending on whether or not the device is mounted, there are three possibilities that can be shown here: /dev/XXX when not mounted /dev/XXX mounted on /media/when mounted /dev/XXX mounted if mounted but the mount point is not available Please be gentle, this is my first QML patch :-) This addresses bug 196939. http://bugs.kde.org/show_bug.cgi?id=196939 Diffs - plasma/generic/applets/devicenotifier/package/contents/ui/DeviceItem.qml 396de2c Diff: http://git.reviewboard.kde.org/r/106755/diff/ Testing --- Built kde-workspace with this change, observed operation and display of device notifier with a selection of removable devices. Screenshots --- Device notifier with mounted device http://git.reviewboard.kde.org/r/106755/s/756/ Thanks, Jonathan Marten
Re: Review Request: Device notifier: show mounted device and path
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106755/#review20039 --- I do not want the notifier to show this information in the device view; indeed, for devices with a label, the mount point is /media/label, so the information about the mount point would look like quite redundant. Perhaps you could show it in a tooltip, instead; that would be acceptable imho In any case, the “trouble with unmounting” usecase should be resolved in some other way (e.g. by making use of lsof in solid to identify blocking apps), so I am not super-sure that the user should be given such specific information as /dev/. - Jacopo De Simoi On Oct. 7, 2012, 2:55 p.m., Jonathan Marten wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106755/ --- (Updated Oct. 7, 2012, 2:55 p.m.) Review request for KDE Base Apps and Plasma. Description --- If a removable device is mounted using the Plasma device notifier, there is no indication of what the Unix name of the device is or where it is mounted. This information may be useful to the user for (a) accessing the mounted device from non-KDE applications, or (b) troubleshooting mounting or unmounting problems. The attached patch shows this information when the device is hovered over, just above the N actions for this device text. Depending on whether or not the device is mounted, there are three possibilities that can be shown here: /dev/XXX when not mounted /dev/XXX mounted on /media/when mounted /dev/XXX mounted if mounted but the mount point is not available Please be gentle, this is my first QML patch :-) This addresses bug 196939. http://bugs.kde.org/show_bug.cgi?id=196939 Diffs - plasma/generic/applets/devicenotifier/package/contents/ui/DeviceItem.qml 2a9b3f7 Diff: http://git.reviewboard.kde.org/r/106755/diff/ Testing --- Built kde-workspace with this change, observed operation and display of device notifier with a selection of removable devices. Screenshots --- Device notifier with mounted device http://git.reviewboard.kde.org/r/106755/s/756/ Thanks, Jonathan Marten
Default file manager and folder associations
Dear kcd, I am thinking for a possible fix for bug #293576 [1], but I could not make up my mind so far. As far as I understand the situation is as follows: - There is no explicit way of setting the default file manager for the KDE workspace; however, there is an implicit way of doing that by selecting the desired program as the default file association for folders. - When the user adds a new file association by rightclick open with... other + tick “remember file association” the newly added program is set as default for the corresponding mimetype. This two behaviors together sum up to bug 293576: a user wants to open a folder with a random program (that is VLC in the br); he therefore adds the corresponding action via the rightclick business described above. This selects VLC as the default file association for folders, and forces applications to believe that VLC is our default file manager. In particular the device notifier is easily fooled by this situation, and opens every device with vlc :( The reporter was kind enough to document this with a video [2] So far I came up with a couple of solutions, but all do require some feedback: 1) Create an explicit way to set the default file manager (which might or might not necessarily be the default association for folders) so that the user cannot change it without noticing. 2) “Protect” folders as a special type of file and disallow to set a random application as default unless explicitly requested using the kcm My first thought was that this was really a corner usecase, and it very possibly is; however, I must admit that this behavior is indeed quite bizarre (please do have a look at the video) and, unless you really know what is going on, it does seems to make little or no sense at all. Other solutions are of course most welcome. Thanks, Jacopo [1] http://bugs.kde.org/show_bug.cgi?id=293576 [2] http://www.youtube.com/watch?v=tPQaUKIBwCc
Re: Default file manager and folder associations
On Sunday 17 June 2012 12:21:07 todd rme wrote: On Sun, Jun 17, 2012 at 11:13 AM, Jacopo De Simoi wilder...@gmail.com wrote: Dear kcd, I am thinking for a possible fix for bug #293576 [1], but I could not make up my mind so far. As far as I understand the situation is as follows: - There is no explicit way of setting the default file manager for the KDE workspace; however, there is an implicit way of doing that by selecting the desired program as the default file association for folders. What about system settings - Default Applications - File Manager? Hey, I actually never happened to use this kcm, and did not find any reference to it by googling around “change default file manager in kde”. Todd, thanks a lot for the insight! So, I need to take back my observation about the lack of an “explicit” way of dealing with this setting. Still, it seems that this kcm is a simply another way to set the default association for folders, that is, it suffers from the same issue that I described before. Any comments on the proposed solutions? Perhaps we could somehow decouple the kcm Todd mentioned from the default folder association? Thanks again, __J
Re: Default file manager and folder associations
On Sunday 17 June 2012 19:17:41 Thomas Lübking wrote: You want to open directories with the default mime handler just as images or an mp3, that's why they're there. If someone sets an rm -rf $1 script as default directory handler, that's actually his problem - you can't fix stupidity. I perfectly agree ;) However, the user never meant to change the default association for folders, he just meant to add a new action to the right-click menu. so in the end I agree with you that the crucial issue is the misleading caption of the checkbox in the “open with…” dialog. Who is the right person to discuss with? Thanks, Jacopo
Conflict in merging kde-workspace KDE/4.8 → master
Hi guys, I tried to merge forward the KDE/4.8 branch to master and I got the following error Auto-merging kdm/kfrontend/themes/ariya/KdmGreeterTheme.desktop CONFLICT (add/add): Merge conflict in kdm/kfrontend/themes/ariya/KdmGreeterTheme.desktop Automatic merge failed; fix conflicts and then commit the result. What should be done to take care of this? Thanks __J
Re: Review Request: Add isInUse() method to StorageDrive interface
--- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5770/ --- (Updated 2010-11-10 14:57:02.366292) Review request for kdelibs, Will Stephenson and Kevin Ottens. Changes --- Reverse logic, now we have a method isInUse, as suggested by wstephenson. Summary (updated) --- This patch adds a isInUse() method in the StorageDrive interface. The usecase for this are applications that need to know if it is possible to safely unplug a device by checking that the isInUse() property on the parent drive is false. Diffs (updated) - trunk/KDE/kdelibs/solid/solid/storagedrive.h 1195159 trunk/KDE/kdelibs/solid/solid/storagedrive.cpp 1195159 Diff: http://svn.reviewboard.kde.org/r/5770/diff Testing --- Thanks, Jacopo
Review Request: Add DevicePrivate pointer to DeviceInterfacePrivate
--- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5769/ --- Review request for kdelibs and Kevin Ottens. Summary --- This patch adds a DevicePrivate pointer to the private class DeviceInterfacePrivate. Diffs - trunk/KDE/kdelibs/solid/solid/device.cpp 1193078 trunk/KDE/kdelibs/solid/solid/deviceinterface.cpp 1193078 trunk/KDE/kdelibs/solid/solid/deviceinterface_p.h 1193078 Diff: http://svn.reviewboard.kde.org/r/5769/diff Testing --- Thanks, Jacopo
