Re: KRunner plugin documentation
Am Mittwoch, 7. Dezember 2011, 12:09:30 schrieb Andras Mantia: Yes (after I wrote the mail :) ), I have two problem with it: - it is not readable (partly due to that is is semi-transparent, and that is lists all the plugins, so you have 10+ entries starting with search term) I never understood what kind of usability philosophy supports having a list of several dozen entries but only one visible at a time. - it doesn't describe everything, e.g unit converters. So I keep my statement that a per-plugin documentation is needed. A long time ago I suggested to put some info into the list where you enable/disable the plugins. Currently the info button is useless because it does not hold any useful information or help about the plugin but just some copyright info. So either make that info button useful by adding info about the plug-in's features or add a second button. Since that button would be called info or help as well and get the same icon, it shows how useless the current has been since it was introduced, i.e. it lacks the obvious content its icon and name mediate. Sven. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Battery plasmoid auto hide
On Thursday 28 July 2011 01:48:32 Aaron J. Seigo wrote: On Wednesday, July 27, 2011 21:02:19 Sven Burmeister wrote: So if one follows your argument that it should only hide if it has usefulinformation the only state it should hide would be fully charged and on power. which is what it does. Ok, to clarify. While the battery is charging the icon is displayed in the systray? Sven ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Battery plasmoid auto hide
On Wednesday 27 July 2011 12:45:42 Marco Martin wrote: the concept is to show the plasmoid only when useful, i.e when is on battery, in which case has useful information. The current charging status (%) is useful information, either because one wants to un-plug the cable at 100% or because one wants to know whether one can get going without running out of battery in the middle of the journey. Both of these things would require multiple clicks if the battery was hidden. So if one follows your argument that it should only hide if it has useful information the only state it should hide would be fully charged and on power. How do other OSs handle this? Does Apple hide it? Is it hidden on smartphones where the space for a systray is certainly most limited compared to other devices? If not – there might be a reason. Sven ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Systray jobs and notifications
Am Montag, 6. April 2009 16:30:21 schrieb Rob Scheepmaker: Hello, I wanted to discuss what I think should be improved in the plasma systemtray... not the spec, but the jobs/notifications. We discussed some of this already at tokamak, but there's still a lot to be done if we want this to be implemented for 4.3: Even if the icon gets some animation, it is still small and the event notification closed is still the same, i.e. the signal remains the same as the user might just notice the it's gone and not whereto. There have been people stating that they thought the job was done because the notification was closed. They e.g. pulled the cable or shut-down the computer. To solve this, progress jobs should not be hidden by default. If the user hides it and forgets about it afterwards, that's his fault. Currently it is only possible to either hide all notification or show all (clicking on the icon), which I think could be improved too, i.e. let the user hide/collapse individual notifications. Further, the notifications cannot be detached (if one wants them to stay on the desktop) if the desktop/panel is locked, which I think does not make sense, because it is just annoying having to unlock/drag/re-lock just to detach a notification. Sven ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: removing unuseful settings
Am Freitag, 17. Oktober 2008 20:10:50 schrieb Aaron J. Seigo: On Friday 17 October 2008, Alexis Ménard wrote: yes but what about the time that it stay displayed? as anyone actually complained about that? If they can change it, why should they complain? Sven ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kdreview check in
Am Dienstag, 14. Oktober 2008 02:07:19 schrieb Aaron J. Seigo: * to hear any objections from anyone for any specific component in kdreview. speak now, or forever hold your peace sort of thing. http://mail.kde.org/pipermail/plasma-devel/2008-October/001379.html This is still unanswered. Sven ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: calendar widget in kdereview
Am Donnerstag, 2. Oktober 2008 23:47:29 schrieb Davide Bettio: I just moved the calendar widget to kdereview/plasma/widgets. In case this is supposed to replace the current datepicker that pops up when clicking on a clock: When introducing KDE 4.0, there was a discussion on kde-usability about the functionality a datepicker needs. I don't think it is a good idea to replace the current datepicker by something that does not include the results of those dicussions. Artists should not ignore these things. The datepicker you showed on your blog lacks all functionality the current datepicker has in the bottom line, jump to today, selectable date and current week. Please make sure to fix this before you move it out of kdereview. Sven http://www.nabble.com/KDatePicker-usability-attempt,-contd.-to15536443.html http://www.nabble.com/KDatePicker-usability-attempt-to13707097.html especially: http://www.nabble.com/KDatePicker-usability-attempt- to13707097.html#a13737003 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
