Re: Review Request 110431: Improve battery monitor with multiple batteries
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/110431/#review32544
---
I didn't know how to do this when it's inside a model
This should really be done inside the model. The visualization should remain
just that: a visualization, and the model should do all the data manipulation.
- Aaron J. Seigo
On May 14, 2013, 9:50 p.m., Kai Uwe Broulik wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/110431/
---
(Updated May 14, 2013, 9:50 p.m.)
Review request for Plasma and Viranch Mehta.
Description
---
This patch improves the situation with multiple batteries in the battery
monitor by:
- Showing the device name instead of just Battery, ie. your Mouse, if it
has a name, will say Your awesome bluetooth mouse
- Not adding non-powersupply-batteries (eg. mice and others) to the total
percentage
Non-power-supply don't get the (charging) suffix as, according to the spec,
the chargeState property is not available for such devices and they're always
considered discharging, eliminating the usefulness of this label.
I removed the Battery 1, Battery 2 naming from the Popup since it didn't
work in the first place (only showed Battery here) and I wanted to make it
as smart as the tooltip, which, if there is only one battery without a name,
it says Battery instead of Battery 1 and if there are, it doesn't just
show Battery $index but Battery 1, Battery 2, but I didn't know how to
do this when it's inside a model. Can I have a variable there in QML, like:
Repeater {
…
batteryNumer: model[Name] ? batteryNumber++ : batteryNumber
}
so I can skip the named ones and don't end up with Battery 1, My mouse
battery, Battery 3?
I'm also not sure about the Show battery percentage for each individual
battery setting. Not showing non-powersupply-batteries if unchecked is
certainly not an option, but if you just collapse powersupply batteries, you
will still end up with more than one battery in the popup, despite its name.
So maybe we should drop it altogether and always show all batteries in the
popup but only show one icon (that is the sum of all powersupply batteries)
on the icon? It shows multiple icons (ie. one for each battery) when placed
on the desktop anyway …
Diffs
-
plasma/generic/applets/batterymonitor/contents/code/logic.js 974694a
plasma/generic/applets/batterymonitor/contents/config/main.xml fc31b3e
plasma/generic/applets/batterymonitor/contents/ui/PopupDialog.qml 3ffb15f
plasma/generic/applets/batterymonitor/contents/ui/batterymonitor.qml
c69c3a5
Diff: http://git.reviewboard.kde.org/r/110431/diff/
Testing
---
I only have a notebook with a bluetooth mouse, so I couldn't test how it
behaves on a desktop machine that doesn't have an internal battery but just a
mouse battery attached, or how it behaves with more than one primary battery.
More testing is needed.
File Attachments
Popup Dialog
http://git.reviewboard.kde.org/media/uploaded/files/2013/05/14/bluetoothmouse4.png
Thanks,
Kai Uwe Broulik
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 110430: [Taskbar applet] Added actions to be perfomed on middle click
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110430/#review32545 --- I am not in favour of this patch for a couple of reasons. First, there is a port underway to QML which does not need to be delayed further by adding more features. More importantly, however, middle click is a special case of not the first two mouse buttons (should we support N button mice?) and it adds yet more configuration to an already complex and full configuration dialog. It also conflicts with the meaning of middle click to expand / collapse groups (a fairly hidden feature I also was not particularly happy with tbh). - Aaron J. Seigo On May 14, 2013, 10:35 p.m., Albert Vaca Cintora wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110430/ --- (Updated May 14, 2013, 10:35 p.m.) Review request for kde-workspace and Plasma. Description --- This patch adds a feature present in KDE3 and requested by some users (see open bugs), that is performing an action when a taskbar entry is middle-clicked. I have added three possible actions: Close the application, hide it or move it to the current desktop, where the first two were user requests. This addresses bugs 182689 and 190951. http://bugs.kde.org/show_bug.cgi?id=182689 http://bugs.kde.org/show_bug.cgi?id=190951 Diffs - plasma/desktop/applets/tasks/tasks.h fe79a12 plasma/desktop/applets/tasks/tasks.cpp 0a86dcf plasma/desktop/applets/tasks/tasksConfig.ui 6f3ff18 plasma/desktop/applets/tasks/windowtaskitem.cpp f840076 Diff: http://git.reviewboard.kde.org/r/110430/diff/ Testing --- Manual testing. Thanks, Albert Vaca Cintora ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 110427: Allow Plasma::ConfigLoader to load default QColor values that contain alpha channel
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110427/ --- (Updated May 15, 2013, 9:47 a.m.) Review request for Plasma, Aaron J. Seigo and Marco Martin. Changes --- Removed first part, it's not possible to do it that way (Qt documentation was misleading). Description --- This patch aims to allow Plasma::ConfigLoader to properly load default values of QColor that contains alpha channel (bug #318504). Apparently constructor of QColor which takes QString as value fails to detect and properly (QColor with alpha channel is handled properly by KConfigGroup). This addresses bug 318504. http://bugs.kde.org/show_bug.cgi?id=318504 Diffs (updated) - plasma/configloader.cpp 5c67474 Diff: http://git.reviewboard.kde.org/r/110427/diff/ Testing (updated) --- Compiles, not tested yet. Thanks, Michał Dutkiewicz ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Default activity naming issues
Hi all, I know everybody is busy with plasma2 (even I manage to find some time to play around with it, unfortunately not more than that), but there is one issue that I'd like to raise regarding the current release. The default name for the default activity 'Desktop' is causing a few problems. Firstly, people (iirc, it was even on some podcast like LAS) are confused why would we write Desktop on a desktop like they don't know already what it is. The problem with the name is that no real person's task/project/activity would have this name. Another issue is that when the user right-clicks a file, she gets a menu item Activities-Link to Desktop. And she then thinks it will create a symbolic link to the desktop. Which it doesn't. In Plasma Active, it would do something similar, but not for the plasma-desktop. Cheerio, Ivan -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Default activity naming issues
On Wednesday 15 May 2013 09:59:40 Ivan Čukić wrote: Hi all, I know everybody is busy with plasma2 (even I manage to find some time to play around with it, unfortunately not more than that), but there is one issue that I'd like to raise regarding the current release. The default name for the default activity 'Desktop' is causing a few problems. Firstly, people (iirc, it was even on some podcast like LAS) are confused why would we write Desktop on a desktop like they don't know already what it is. hmm, maybe the default name (being Desktop, New Activity # or whatever) should not appear in the toolbox until explicitly renamed? in the same way, what to display in the activity switcher? what could be a really meaningful name? -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: PotD Headers
On Tuesday 14 May 2013 22:50:00 David Narvaez wrote: Hi, Would it be a goog idea the following two headers from the kdeplasma-addons repository? dataengines/potd/plasma_potd_export.h dataengines/potd/potdprovider.h This would ease development of new providers. that would make it a public library, with the promise of more quality and absolute binary stability that this brings.. would be fine,.. as long someone commits to maintain a library with such a promise (that would probably require some refactor to be ready, such as being all based on dpointers) -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: PotD Headers
On Tuesday, May 14, 2013 22:50:00 David Narvaez wrote: Would it be a goog idea the following two headers from the kdeplasma-addons repository? As sebas noted, this would require a maintainer to step up to maintain the API of that class. What I'd much rather see is Javascript glue so that instead of writing more C++ plugins, we can deliver platform-independent JS backends .. which would allow us to update them when the host provider changes their web service and also to offer them via GHNS. -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: PotD Headers
On Wednesday 15 May 2013 08:40:06 Marco Martin wrote: On Tuesday 14 May 2013 22:50:00 David Narvaez wrote: Hi, Would it be a goog idea the following two headers from the kdeplasma-addons repository? dataengines/potd/plasma_potd_export.h dataengines/potd/potdprovider.h This would ease development of new providers. that would make it a public library, with the promise of more quality and absolute binary stability that this brings.. would be fine,.. as long someone commits to maintain a library with such a promise (that would probably require some refactor to be ready, such as being all based on dpointers) as it's in kdeplasma-addons the binary stability should not matter as long as the so version is increased with each release. Still it would be against what we are used to have and I'm not sure whether our packagers would be happy about having kdeplasma-addons as a build dep. -- Martin Gräßlin signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Default activity naming issues
On Wednesday, May 15, 2013 09:59:40 Ivan ÄukiÄ wrote: The default name for the default activity 'Desktop' is causing a few problems. glad these are the kinds of problems we face these days :) hm.. brainstorm Main Activity Home Home Activity ... -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 110413: Show in the tasks applet the activities a task is available on
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110413/ --- (Updated May 15, 2013, 9:03 a.m.) Review request for Plasma. Changes --- New version of the patch. It solves the issues reported. Description --- This patch adds information about the activities on which a task is available to the tooltip. Two methods to obtain information about the activities a task is available, activities and activityNames, where added to TaskManager::TaskItem. Depending whether the applet is configured to show tasks which are not available in the current activity or not, the information displayed will be different. If the applet is configured to show only tasks in current activity, only the tasks which are also available in other activities will have this information in the tooltip. This addresses bug 307163. http://bugs.kde.org/show_bug.cgi?id=307163 Diffs (updated) - libs/taskmanager/taskitem.h 35606e2 libs/taskmanager/taskitem.cpp c9613c9 plasma/desktop/applets/tasks/windowtaskitem.cpp f840076 Diff: http://git.reviewboard.kde.org/r/110413/diff/ Testing --- In order to test this patch, three activities (called Activity 1, Activity 2 and Activity 3) were created. Various instances of KDialog were created, all of them in desktop 1, and they were assigned to various activities (The title of the dialog was set to AxDi, where x are the activities on which the dialog will be available). All screenshots were taken on activity 1. Screenshots 1 to 3 were taken with the taskbar configured to display tasks in all activities but only in desktop 1. Screenshots 4 to 6 were taken with the configuration to show tasks only in current activity. Screenshot 7 was taken with the taskbar displaying all tasks from all desktops. Screenshot 8 was created with the taskbar configured to group elements by program (activity information is not yet available). File Attachments Screenshot 1 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/13/snapshot1.png Screenshot 2 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/13/snapshot2.png Screenshot 3 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/13/snapshot3.png Screenshot 4 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/13/snapshot4.png Screenshot 5 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/13/snapshot5.png Screenshot 6 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/13/snapshot6.png Screenshot 7 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/13/snapshot7.png Screenshot 8 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/13/snapshot8.png Thanks, José Millán Soto ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Default activity naming issues
glad these are the kinds of problems we face these days :) +10 Main Activity Thinking this would be better than the rest. (link to home could also be expected to create a symlink) Ch! ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Default activity naming issues
On Wed, May 15, 2013 at 10:54 AM, Aaron J. Seigo ase...@kde.org wrote: On Wednesday, May 15, 2013 09:59:40 Ivan Čukić wrote: The default name for the default activity 'Desktop' is causing a few problems. glad these are the kinds of problems we face these days :) hm.. brainstorm Main Activity Home Note that 'Home' is pretty much the same case as Desktop - it's a directory, also visible by default in Places sidebar in Dolphin or file dialogs. Cheers -- Martin Klapetek | KDE Developer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 110436: Add an option to disable the dimming of minimized windows
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110436/ --- Review request for Plasma. Description --- The grayscale dimming effect applied to minimized windows in the task bar can be detrimental to usability to some people, as the lack of color makes it harder to distinguish a specific application. This commit introduces an option to disable this behavior. This addresses bug 311991. http://bugs.kde.org/show_bug.cgi?id=311991 Diffs - plasma/desktop/applets/tasks/abstracttaskitem.cpp 988b6a8da8c7b71b0e2efde4255bba3b4334e860 plasma/desktop/applets/tasks/tasks.h fe79a12088a8375113c3ee8f9191c6669138256d plasma/desktop/applets/tasks/tasks.cpp 0a86dcf57868a230cdda1a43aa35c3e95260c042 plasma/desktop/applets/tasks/tasksConfig.ui 6f3ff1825ddafc0e0dffc71eb7157978589cc663 Diff: http://git.reviewboard.kde.org/r/110436/diff/ Testing --- Thanks, Veeti Paananen ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 110436: Add an option to disable the dimming of minimized windows
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110436/ --- (Updated May 15, 2013, 9:18 a.m.) Review request for Plasma. Description --- The grayscale dimming effect applied to minimized windows in the task bar can be detrimental to usability to some people, as the lack of color makes it harder to distinguish a specific application. This commit introduces an option to disable this behavior. This addresses bug 311991. http://bugs.kde.org/show_bug.cgi?id=311991 Diffs - plasma/desktop/applets/tasks/abstracttaskitem.cpp 988b6a8da8c7b71b0e2efde4255bba3b4334e860 plasma/desktop/applets/tasks/tasks.h fe79a12088a8375113c3ee8f9191c6669138256d plasma/desktop/applets/tasks/tasks.cpp 0a86dcf57868a230cdda1a43aa35c3e95260c042 plasma/desktop/applets/tasks/tasksConfig.ui 6f3ff1825ddafc0e0dffc71eb7157978589cc663 Diff: http://git.reviewboard.kde.org/r/110436/diff/ Testing --- Thanks, Veeti Paananen ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Default activity naming issues
On Wednesday 15 May 2013 10:54:15 Aaron J. Seigo wrote: On Wednesday, May 15, 2013 09:59:40 Ivan ÄukiÄ wrote: The default name for the default activity 'Desktop' is causing a few problems. glad these are the kinds of problems we face these days :) hm.. brainstorm Main Activity Home Home Activity ... Just to throw one in the hat to not feel too useless: Welcome Welcome Activity Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 110431: Improve battery monitor with multiple batteries
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/110431/
---
(Updated May 15, 2013, 10:51 a.m.)
Review request for Plasma and Viranch Mehta.
Changes
---
Delegated creating the battery pretty name to the dataengine.
Description
---
This patch improves the situation with multiple batteries in the battery
monitor by:
- Showing the device name instead of just Battery, ie. your Mouse, if it has
a name, will say Your awesome bluetooth mouse
- Not adding non-powersupply-batteries (eg. mice and others) to the total
percentage
Non-power-supply don't get the (charging) suffix as, according to the spec,
the chargeState property is not available for such devices and they're always
considered discharging, eliminating the usefulness of this label.
I removed the Battery 1, Battery 2 naming from the Popup since it didn't
work in the first place (only showed Battery here) and I wanted to make it as
smart as the tooltip, which, if there is only one battery without a name, it
says Battery instead of Battery 1 and if there are, it doesn't just show
Battery $index but Battery 1, Battery 2, but I didn't know how to do this
when it's inside a model. Can I have a variable there in QML, like:
Repeater {
…
batteryNumer: model[Name] ? batteryNumber++ : batteryNumber
}
so I can skip the named ones and don't end up with Battery 1, My mouse battery,
Battery 3?
I'm also not sure about the Show battery percentage for each individual
battery setting. Not showing non-powersupply-batteries if unchecked is
certainly not an option, but if you just collapse powersupply batteries, you
will still end up with more than one battery in the popup, despite its name. So
maybe we should drop it altogether and always show all batteries in the popup
but only show one icon (that is the sum of all powersupply batteries) on the
icon? It shows multiple icons (ie. one for each battery) when placed on the
desktop anyway …
Diffs (updated)
-
plasma/generic/applets/batterymonitor/contents/code/logic.js 974694a
plasma/generic/applets/batterymonitor/contents/config/main.xml fc31b3e
plasma/generic/applets/batterymonitor/contents/ui/PopupDialog.qml 3ffb15f
plasma/generic/applets/batterymonitor/contents/ui/batterymonitor.qml c69c3a5
plasma/generic/dataengines/powermanagement/powermanagementengine.h 1809c02
plasma/generic/dataengines/powermanagement/powermanagementengine.cpp 7882f75
Diff: http://git.reviewboard.kde.org/r/110431/diff/
Testing
---
I only have a notebook with a bluetooth mouse, so I couldn't test how it
behaves on a desktop machine that doesn't have an internal battery but just a
mouse battery attached, or how it behaves with more than one primary battery.
More testing is needed.
File Attachments
Popup Dialog
http://git.reviewboard.kde.org/media/uploaded/files/2013/05/14/bluetoothmouse4.png
Thanks,
Kai Uwe Broulik
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 110430: [Taskbar applet] Added actions to be perfomed on middle click
On May 15, 2013, 6:06 a.m., Aaron J. Seigo wrote: I am not in favour of this patch for a couple of reasons. First, there is a port underway to QML which does not need to be delayed further by adding more features. More importantly, however, middle click is a special case of not the first two mouse buttons (should we support N button mice?) and it adds yet more configuration to an already complex and full configuration dialog. It also conflicts with the meaning of middle click to expand / collapse groups (a fairly hidden feature I also was not particularly happy with tbh). Hello Aaron and thank for your reply. Let me defend the inclusion of this patch from the problems you mention: - Difficulty to port to QML: This feature is implemented in a ~10 lines switch (not counting the GUI-related code), so porting it should not be a problem (I could do it, if needed). - Support for N button mice: The desktop should adapt to the current hardware, and nowadays most mice have 3 buttons (not N, but neither only 2). Moreover, lots of apps have adopted the behaviour of closing tabs with a middle click, so adding this feature for applications in the taskbar is consistent with them. - Complexity of the configuration dialog: I agree that we should try to keep all the configuration dialogs simple, but not adding new features because of that reminds me of Gnome3 ;) I think this is not solution for the long-discussed problem of the user-friendliness. Finally, and more important, it has 2 open bugs (+ 4 duplicates) so there are real users requesting it. If it's not going to be added, those bugs should be marked as wontfix. - Albert --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110430/#review32545 --- On May 14, 2013, 10:35 p.m., Albert Vaca Cintora wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110430/ --- (Updated May 14, 2013, 10:35 p.m.) Review request for kde-workspace and Plasma. Description --- This patch adds a feature present in KDE3 and requested by some users (see open bugs), that is performing an action when a taskbar entry is middle-clicked. I have added three possible actions: Close the application, hide it or move it to the current desktop, where the first two were user requests. This addresses bugs 182689 and 190951. http://bugs.kde.org/show_bug.cgi?id=182689 http://bugs.kde.org/show_bug.cgi?id=190951 Diffs - plasma/desktop/applets/tasks/tasks.h fe79a12 plasma/desktop/applets/tasks/tasks.cpp 0a86dcf plasma/desktop/applets/tasks/tasksConfig.ui 6f3ff18 plasma/desktop/applets/tasks/windowtaskitem.cpp f840076 Diff: http://git.reviewboard.kde.org/r/110430/diff/ Testing --- Manual testing. Thanks, Albert Vaca Cintora ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Default activity naming issues
Welcome is nice, but again, not a real activity (link to Welcome and similar). Cheerio On 15 May 2013 11:49, Kevin Ottens er...@kde.org wrote: On Wednesday 15 May 2013 10:54:15 Aaron J. Seigo wrote: On Wednesday, May 15, 2013 09:59:40 Ivan ÄŒukić wrote: The default name for the default activity 'Desktop' is causing a few problems. glad these are the kinds of problems we face these days :) hm.. brainstorm Main Activity Home Home Activity ... Just to throw one in the hat to not feel too useless: Welcome Welcome Activity Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 110413: Show in the tasks applet the activities a task is available on
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110413/#review32563 --- Ship it! Ship It! - Aaron J. Seigo On May 15, 2013, 9:03 a.m., José Millán Soto wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110413/ --- (Updated May 15, 2013, 9:03 a.m.) Review request for Plasma. Description --- This patch adds information about the activities on which a task is available to the tooltip. Two methods to obtain information about the activities a task is available, activities and activityNames, where added to TaskManager::TaskItem. Depending whether the applet is configured to show tasks which are not available in the current activity or not, the information displayed will be different. If the applet is configured to show only tasks in current activity, only the tasks which are also available in other activities will have this information in the tooltip. This addresses bug 307163. http://bugs.kde.org/show_bug.cgi?id=307163 Diffs - libs/taskmanager/taskitem.h 35606e2 libs/taskmanager/taskitem.cpp c9613c9 plasma/desktop/applets/tasks/windowtaskitem.cpp f840076 Diff: http://git.reviewboard.kde.org/r/110413/diff/ Testing --- In order to test this patch, three activities (called Activity 1, Activity 2 and Activity 3) were created. Various instances of KDialog were created, all of them in desktop 1, and they were assigned to various activities (The title of the dialog was set to AxDi, where x are the activities on which the dialog will be available). All screenshots were taken on activity 1. Screenshots 1 to 3 were taken with the taskbar configured to display tasks in all activities but only in desktop 1. Screenshots 4 to 6 were taken with the configuration to show tasks only in current activity. Screenshot 7 was taken with the taskbar displaying all tasks from all desktops. Screenshot 8 was created with the taskbar configured to group elements by program (activity information is not yet available). File Attachments Screenshot 1 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/13/snapshot1.png Screenshot 2 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/13/snapshot2.png Screenshot 3 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/13/snapshot3.png Screenshot 4 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/13/snapshot4.png Screenshot 5 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/13/snapshot5.png Screenshot 6 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/13/snapshot6.png Screenshot 7 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/13/snapshot7.png Screenshot 8 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/13/snapshot8.png Thanks, José Millán Soto ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 110427: Allow Plasma::ConfigLoader to load default QColor values that contain alpha channel
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110427/#review32568 --- This version compiles! :) Progress.. Please add a test case to tests/configloader.cpp to confirm that this works and then it may be committed. Thanks! - Aaron J. Seigo On May 15, 2013, 7:47 a.m., Michał Dutkiewicz wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110427/ --- (Updated May 15, 2013, 7:47 a.m.) Review request for Plasma, Aaron J. Seigo and Marco Martin. Description --- This patch aims to allow Plasma::ConfigLoader to properly load default values of QColor that contains alpha channel (bug #318504). Apparently constructor of QColor which takes QString as value fails to detect and properly (QColor with alpha channel is handled properly by KConfigGroup). This addresses bug 318504. http://bugs.kde.org/show_bug.cgi?id=318504 Diffs - plasma/configloader.cpp 5c67474 Diff: http://git.reviewboard.kde.org/r/110427/diff/ Testing --- Compiles, not tested yet. Thanks, Michał Dutkiewicz ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 110431: Improve battery monitor with multiple batteries
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/110431/#review32569
---
I'm also not sure about the Show battery percentage for each individual
battery setting. Not showing non-powersupply-batteries if unchecked is
certainly not an option, but if you just collapse powersupply batteries, you
will still end up with more than one battery in the popup, despite its name. So
maybe we should drop it altogether and always show all batteries in the popup
but only show one icon (that is the sum of all powersupply batteries) on the
icon?
Yes, I like this idea a lot. With that modification, I think this should go
into master where we can get wider testing by people with desktops and
interesting battery configurations. Nice work :)
- Aaron J. Seigo
On May 15, 2013, 10:51 a.m., Kai Uwe Broulik wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/110431/
---
(Updated May 15, 2013, 10:51 a.m.)
Review request for Plasma and Viranch Mehta.
Description
---
This patch improves the situation with multiple batteries in the battery
monitor by:
- Showing the device name instead of just Battery, ie. your Mouse, if it
has a name, will say Your awesome bluetooth mouse
- Not adding non-powersupply-batteries (eg. mice and others) to the total
percentage
Non-power-supply don't get the (charging) suffix as, according to the spec,
the chargeState property is not available for such devices and they're always
considered discharging, eliminating the usefulness of this label.
I removed the Battery 1, Battery 2 naming from the Popup since it didn't
work in the first place (only showed Battery here) and I wanted to make it
as smart as the tooltip, which, if there is only one battery without a name,
it says Battery instead of Battery 1 and if there are, it doesn't just
show Battery $index but Battery 1, Battery 2, but I didn't know how to
do this when it's inside a model. Can I have a variable there in QML, like:
Repeater {
…
batteryNumer: model[Name] ? batteryNumber++ : batteryNumber
}
so I can skip the named ones and don't end up with Battery 1, My mouse
battery, Battery 3?
I'm also not sure about the Show battery percentage for each individual
battery setting. Not showing non-powersupply-batteries if unchecked is
certainly not an option, but if you just collapse powersupply batteries, you
will still end up with more than one battery in the popup, despite its name.
So maybe we should drop it altogether and always show all batteries in the
popup but only show one icon (that is the sum of all powersupply batteries)
on the icon? It shows multiple icons (ie. one for each battery) when placed
on the desktop anyway …
Diffs
-
plasma/generic/applets/batterymonitor/contents/code/logic.js 974694a
plasma/generic/applets/batterymonitor/contents/config/main.xml fc31b3e
plasma/generic/applets/batterymonitor/contents/ui/PopupDialog.qml 3ffb15f
plasma/generic/applets/batterymonitor/contents/ui/batterymonitor.qml
c69c3a5
plasma/generic/dataengines/powermanagement/powermanagementengine.h 1809c02
plasma/generic/dataengines/powermanagement/powermanagementengine.cpp
7882f75
Diff: http://git.reviewboard.kde.org/r/110431/diff/
Testing
---
I only have a notebook with a bluetooth mouse, so I couldn't test how it
behaves on a desktop machine that doesn't have an internal battery but just a
mouse battery attached, or how it behaves with more than one primary battery.
More testing is needed.
File Attachments
Popup Dialog
http://git.reviewboard.kde.org/media/uploaded/files/2013/05/14/bluetoothmouse4.png
Thanks,
Kai Uwe Broulik
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 110430: [Taskbar applet] Added actions to be perfomed on middle click
On May 15, 2013, 6:06 a.m., Aaron J. Seigo wrote: I am not in favour of this patch for a couple of reasons. First, there is a port underway to QML which does not need to be delayed further by adding more features. More importantly, however, middle click is a special case of not the first two mouse buttons (should we support N button mice?) and it adds yet more configuration to an already complex and full configuration dialog. It also conflicts with the meaning of middle click to expand / collapse groups (a fairly hidden feature I also was not particularly happy with tbh). Albert Vaca Cintora wrote: Hello Aaron and thank for your reply. Let me defend the inclusion of this patch from the problems you mention: - Difficulty to port to QML: This feature is implemented in a ~10 lines switch (not counting the GUI-related code), so porting it should not be a problem (I could do it, if needed). - Support for N button mice: The desktop should adapt to the current hardware, and nowadays most mice have 3 buttons (not N, but neither only 2). Moreover, lots of apps have adopted the behaviour of closing tabs with a middle click, so adding this feature for applications in the taskbar is consistent with them. - Complexity of the configuration dialog: I agree that we should try to keep all the configuration dialogs simple, but not adding new features because of that reminds me of Gnome3 ;) I think this is not solution for the long-discussed problem of the user-friendliness. Finally, and more important, it has 2 open bugs (+ 4 duplicates) so there are real users requesting it. If it's not going to be added, those bugs should be marked as wontfix. porting it should not be a problem (I could do it, if needed). that is definitely a point in your favor. assuming this feature addition is accepted: there's little point to putting it in the c++ version, however, only to put it later in the qml version (which is supposed to be in 4.11). so putting it directly in the QML version would make the most sense. Moreover, lots of apps have adopted the behaviour of closing tabs with a middle click to point out the obvious: windows are not tabs. this also implies that middle click to close is actually a *good* feature. i think it is for power users .. but i have seen too many instances where these kinds of magic click that button and magically something happens features lead to confusion, and confusion leads to distrust of the system as a whole. yes, the default is to do nothing in your patch (+1 for that), but if sitting down to someone else's system results in wildly unpredictable behaviour ... keep in mind this is not a random component, but a default part of every plasma desktop installation, so it has to work better than most. how much faster is middle click versus right-click-close? fast enough to warrant the risk of surprising behaviour for people who aren't expecting it? Complexity of the configuration dialog: I agree that we should try to keep all the configuration dialogs simple currently that page has 11 settings. ad-hoc testing i've done in the past hints that many of these settings are already not understandable to many users. i really don't want to make this worse. several of the plasmoids have room for more options. the taskbar, folderview, clock and system tray are four that really don't. adding feature over feature is leading to an increasing mess that nobody cares to clean up. if this patch introduced a re-think of the configuration presentation so that it is easier to understand and more approachable, i would consider that a fair trade for accepting a feature i'm not particularly in favour of :) but not adding new features because of that reminds me of Gnome3 for future reference: when i see this kind of statement made, i usually add -1 to my overall weighting. i do not agree with many design decisions in other projects, but design can not be done well if it is primarily directed by not being that other group. common sense and reasoning should be applied to each case without the justification of not like them, otherwise we just create the opposite kind of error. it has 2 open bugs (+ 4 duplicates) so there are real users requesting it. for any product with a large enough user base, given enough time and an open feature request tracker, any possible feature will be requested (usually multiple times). this means that any feature, regardless of intrinsic value, can be justified using this argument. (the least useful case of this i've seen is when people submit the feature request, then later a patch and then use the feature request as evidence it is wanted ;) - Aaron J. --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110430/#review32545
Re: Review Request 110436: Add an option to disable the dimming of minimized windows
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110436/#review32575 --- Sorry, we have a general policy of not supporting such pixel pushing configuration settings. 99.9% of the time they just work around a real problem, not by fixing the real problem but by making those affected go through the annoyance of configuration. This also means more code paths and more complexity in the configuration UI which the future maintainer needs to be maintain. My suggestion is to supply some screenshots along with relevant information (e.g. the desktop SVG theme being used if not the default, screen resolution if out of the ordinary, icon set if not oxygen, etc) and post to plasma-devel@kde.org about the issue. If we can determine the root issue, then we can address it. Not work around it. That said, thank you very much for spending the time to fix something you found didn't work for you. I appreciate that effort a lot :) - Aaron J. Seigo On May 15, 2013, 9:18 a.m., Veeti Paananen wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110436/ --- (Updated May 15, 2013, 9:18 a.m.) Review request for Plasma. Description --- The grayscale dimming effect applied to minimized windows in the task bar can be detrimental to usability to some people, as the lack of color makes it harder to distinguish a specific application. This commit introduces an option to disable this behavior. This addresses bug 311991. http://bugs.kde.org/show_bug.cgi?id=311991 Diffs - plasma/desktop/applets/tasks/abstracttaskitem.cpp 988b6a8da8c7b71b0e2efde4255bba3b4334e860 plasma/desktop/applets/tasks/tasks.h fe79a12088a8375113c3ee8f9191c6669138256d plasma/desktop/applets/tasks/tasks.cpp 0a86dcf57868a230cdda1a43aa35c3e95260c042 plasma/desktop/applets/tasks/tasksConfig.ui 6f3ff1825ddafc0e0dffc71eb7157978589cc663 Diff: http://git.reviewboard.kde.org/r/110436/diff/ Testing --- Thanks, Veeti Paananen ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 110436: Add an option to disable the dimming of minimized windows
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110436/ --- (Updated May 15, 2013, 2:16 p.m.) Status -- This change has been discarded. Review request for Plasma. Description --- The grayscale dimming effect applied to minimized windows in the task bar can be detrimental to usability to some people, as the lack of color makes it harder to distinguish a specific application. This commit introduces an option to disable this behavior. This addresses bug 311991. http://bugs.kde.org/show_bug.cgi?id=311991 Diffs - plasma/desktop/applets/tasks/abstracttaskitem.cpp 988b6a8da8c7b71b0e2efde4255bba3b4334e860 plasma/desktop/applets/tasks/tasks.h fe79a12088a8375113c3ee8f9191c6669138256d plasma/desktop/applets/tasks/tasks.cpp 0a86dcf57868a230cdda1a43aa35c3e95260c042 plasma/desktop/applets/tasks/tasksConfig.ui 6f3ff1825ddafc0e0dffc71eb7157978589cc663 Diff: http://git.reviewboard.kde.org/r/110436/diff/ Testing --- Thanks, Veeti Paananen ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Default activity naming issues
On Wednesday 15 May 2013 15:31:16 Ivan Čukić wrote: Welcome is nice, but again, not a real activity (link to Welcome and similar). Yeah, I guess it comes from some of the adjustments I have in mind for the overall activity workflow. I'd like a default activity which is the one I get when I login, it'd always be in a clean state (no application started). And at any point in time I could say save as a new activity it'd take the whole content and move it in the new activity (emptying this default activity again). I guess in such a context Welcome would make more sense. For the record, this idea of a modified workflow comes from the fact that you generally start to do stuff with your computer and often realize after the facts that you started a new activity. Ahem... Sorry for the ramblings. :-) Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Default activity naming issues
On Wednesday, May 15, 2013 15:31:16 Ivan ÄukiÄ wrote: Welcome is nice, but again, not a real activity (link to Welcome and similar). If we want a meangingful default name, then I think we have to ask the user ... which brings us back to how nice it would be to have a first-run welcome app that lets you set up your online accounts and things like your user information -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 110430: [Taskbar applet] Added actions to be perfomed on middle click
On May 15, 2013, 8:06 a.m., Aaron J. Seigo wrote: I am not in favour of this patch for a couple of reasons. First, there is a port underway to QML which does not need to be delayed further by adding more features. More importantly, however, middle click is a special case of not the first two mouse buttons (should we support N button mice?) and it adds yet more configuration to an already complex and full configuration dialog. It also conflicts with the meaning of middle click to expand / collapse groups (a fairly hidden feature I also was not particularly happy with tbh). Albert Vaca Cintora wrote: Hello Aaron and thank for your reply. Let me defend the inclusion of this patch from the problems you mention: - Difficulty to port to QML: This feature is implemented in a ~10 lines switch (not counting the GUI-related code), so porting it should not be a problem (I could do it, if needed). - Support for N button mice: The desktop should adapt to the current hardware, and nowadays most mice have 3 buttons (not N, but neither only 2). Moreover, lots of apps have adopted the behaviour of closing tabs with a middle click, so adding this feature for applications in the taskbar is consistent with them. - Complexity of the configuration dialog: I agree that we should try to keep all the configuration dialogs simple, but not adding new features because of that reminds me of Gnome3 ;) I think this is not solution for the long-discussed problem of the user-friendliness. Finally, and more important, it has 2 open bugs (+ 4 duplicates) so there are real users requesting it. If it's not going to be added, those bugs should be marked as wontfix. Aaron J. Seigo wrote: porting it should not be a problem (I could do it, if needed). that is definitely a point in your favor. assuming this feature addition is accepted: there's little point to putting it in the c++ version, however, only to put it later in the qml version (which is supposed to be in 4.11). so putting it directly in the QML version would make the most sense. Moreover, lots of apps have adopted the behaviour of closing tabs with a middle click to point out the obvious: windows are not tabs. this also implies that middle click to close is actually a *good* feature. i think it is for power users .. but i have seen too many instances where these kinds of magic click that button and magically something happens features lead to confusion, and confusion leads to distrust of the system as a whole. yes, the default is to do nothing in your patch (+1 for that), but if sitting down to someone else's system results in wildly unpredictable behaviour ... keep in mind this is not a random component, but a default part of every plasma desktop installation, so it has to work better than most. how much faster is middle click versus right-click-close? fast enough to warrant the risk of surprising behaviour for people who aren't expecting it? Complexity of the configuration dialog: I agree that we should try to keep all the configuration dialogs simple currently that page has 11 settings. ad-hoc testing i've done in the past hints that many of these settings are already not understandable to many users. i really don't want to make this worse. several of the plasmoids have room for more options. the taskbar, folderview, clock and system tray are four that really don't. adding feature over feature is leading to an increasing mess that nobody cares to clean up. if this patch introduced a re-think of the configuration presentation so that it is easier to understand and more approachable, i would consider that a fair trade for accepting a feature i'm not particularly in favour of :) but not adding new features because of that reminds me of Gnome3 for future reference: when i see this kind of statement made, i usually add -1 to my overall weighting. i do not agree with many design decisions in other projects, but design can not be done well if it is primarily directed by not being that other group. common sense and reasoning should be applied to each case without the justification of not like them, otherwise we just create the opposite kind of error. it has 2 open bugs (+ 4 duplicates) so there are real users requesting it. for any product with a large enough user base, given enough time and an open feature request tracker, any possible feature will be requested (usually multiple times). this means that any feature, regardless of intrinsic value, can be justified using this argument. (the least useful case of this i've seen is when people submit the feature request, then later a patch and then use the feature request as evidence it is wanted ;) if this patch
Re: Default activity naming issues
On Wednesday 15 May 2013 16:21:28 Aaron J. Seigo wrote: On Wednesday, May 15, 2013 15:31:16 Ivan ÄukiÄ wrote: Welcome is nice, but again, not a real activity (link to Welcome and similar). If we want a meangingful default name, then I think we have to ask the user ... which brings us back to how nice it would be to have a first-run welcome app that lets you set up your online accounts and things like your user information what are you using your system primarily for? * work * videos * Internet * Lolcats * Other: please fill in - name of default activity -- Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 110430: [Taskbar applet] Added actions to be perfomed on middle click
On May 15, 2013, 6:06 a.m., Aaron J. Seigo wrote: I am not in favour of this patch for a couple of reasons. First, there is a port underway to QML which does not need to be delayed further by adding more features. More importantly, however, middle click is a special case of not the first two mouse buttons (should we support N button mice?) and it adds yet more configuration to an already complex and full configuration dialog. It also conflicts with the meaning of middle click to expand / collapse groups (a fairly hidden feature I also was not particularly happy with tbh). Albert Vaca Cintora wrote: Hello Aaron and thank for your reply. Let me defend the inclusion of this patch from the problems you mention: - Difficulty to port to QML: This feature is implemented in a ~10 lines switch (not counting the GUI-related code), so porting it should not be a problem (I could do it, if needed). - Support for N button mice: The desktop should adapt to the current hardware, and nowadays most mice have 3 buttons (not N, but neither only 2). Moreover, lots of apps have adopted the behaviour of closing tabs with a middle click, so adding this feature for applications in the taskbar is consistent with them. - Complexity of the configuration dialog: I agree that we should try to keep all the configuration dialogs simple, but not adding new features because of that reminds me of Gnome3 ;) I think this is not solution for the long-discussed problem of the user-friendliness. Finally, and more important, it has 2 open bugs (+ 4 duplicates) so there are real users requesting it. If it's not going to be added, those bugs should be marked as wontfix. Aaron J. Seigo wrote: porting it should not be a problem (I could do it, if needed). that is definitely a point in your favor. assuming this feature addition is accepted: there's little point to putting it in the c++ version, however, only to put it later in the qml version (which is supposed to be in 4.11). so putting it directly in the QML version would make the most sense. Moreover, lots of apps have adopted the behaviour of closing tabs with a middle click to point out the obvious: windows are not tabs. this also implies that middle click to close is actually a *good* feature. i think it is for power users .. but i have seen too many instances where these kinds of magic click that button and magically something happens features lead to confusion, and confusion leads to distrust of the system as a whole. yes, the default is to do nothing in your patch (+1 for that), but if sitting down to someone else's system results in wildly unpredictable behaviour ... keep in mind this is not a random component, but a default part of every plasma desktop installation, so it has to work better than most. how much faster is middle click versus right-click-close? fast enough to warrant the risk of surprising behaviour for people who aren't expecting it? Complexity of the configuration dialog: I agree that we should try to keep all the configuration dialogs simple currently that page has 11 settings. ad-hoc testing i've done in the past hints that many of these settings are already not understandable to many users. i really don't want to make this worse. several of the plasmoids have room for more options. the taskbar, folderview, clock and system tray are four that really don't. adding feature over feature is leading to an increasing mess that nobody cares to clean up. if this patch introduced a re-think of the configuration presentation so that it is easier to understand and more approachable, i would consider that a fair trade for accepting a feature i'm not particularly in favour of :) but not adding new features because of that reminds me of Gnome3 for future reference: when i see this kind of statement made, i usually add -1 to my overall weighting. i do not agree with many design decisions in other projects, but design can not be done well if it is primarily directed by not being that other group. common sense and reasoning should be applied to each case without the justification of not like them, otherwise we just create the opposite kind of error. it has 2 open bugs (+ 4 duplicates) so there are real users requesting it. for any product with a large enough user base, given enough time and an open feature request tracker, any possible feature will be requested (usually multiple times). this means that any feature, regardless of intrinsic value, can be justified using this argument. (the least useful case of this i've seen is when people submit the feature request, then later a patch and then use the feature request as evidence it is wanted ;) Martin
Re: Review Request 110431: Improve battery monitor with multiple batteries
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/110431/
---
(Updated May 15, 2013, 3:04 p.m.)
Review request for Plasma and Viranch Mehta.
Changes
---
Remove Show the state for each battery present.
Now, when it is constrained (ie. panel or systray) you get one icon which shows
the power supply average.
When placed on the desktop it shows an icon for each battery present next to
each other.
i.e. the code is now like if the option was always enabled.
Description
---
This patch improves the situation with multiple batteries in the battery
monitor by:
- Showing the device name instead of just Battery, ie. your Mouse, if it has
a name, will say Your awesome bluetooth mouse
- Not adding non-powersupply-batteries (eg. mice and others) to the total
percentage
Non-power-supply don't get the (charging) suffix as, according to the spec,
the chargeState property is not available for such devices and they're always
considered discharging, eliminating the usefulness of this label.
I removed the Battery 1, Battery 2 naming from the Popup since it didn't
work in the first place (only showed Battery here) and I wanted to make it as
smart as the tooltip, which, if there is only one battery without a name, it
says Battery instead of Battery 1 and if there are, it doesn't just show
Battery $index but Battery 1, Battery 2, but I didn't know how to do this
when it's inside a model. Can I have a variable there in QML, like:
Repeater {
…
batteryNumer: model[Name] ? batteryNumber++ : batteryNumber
}
so I can skip the named ones and don't end up with Battery 1, My mouse battery,
Battery 3?
I'm also not sure about the Show battery percentage for each individual
battery setting. Not showing non-powersupply-batteries if unchecked is
certainly not an option, but if you just collapse powersupply batteries, you
will still end up with more than one battery in the popup, despite its name. So
maybe we should drop it altogether and always show all batteries in the popup
but only show one icon (that is the sum of all powersupply batteries) on the
icon? It shows multiple icons (ie. one for each battery) when placed on the
desktop anyway …
Diffs (updated)
-
plasma/generic/applets/batterymonitor/contents/code/logic.js 974694a
plasma/generic/applets/batterymonitor/contents/config/main.xml fc31b3e
plasma/generic/applets/batterymonitor/contents/ui/PopupDialog.qml 3ffb15f
plasma/generic/applets/batterymonitor/contents/ui/batterymonitor.qml c69c3a5
plasma/generic/applets/batterymonitor/contents/ui/config.ui 3df38e2
plasma/generic/dataengines/powermanagement/powermanagementengine.h 1809c02
plasma/generic/dataengines/powermanagement/powermanagementengine.cpp 7882f75
Diff: http://git.reviewboard.kde.org/r/110431/diff/
Testing
---
I only have a notebook with a bluetooth mouse, so I couldn't test how it
behaves on a desktop machine that doesn't have an internal battery but just a
mouse battery attached, or how it behaves with more than one primary battery.
More testing is needed.
File Attachments
Popup Dialog
http://git.reviewboard.kde.org/media/uploaded/files/2013/05/14/bluetoothmouse4.png
Thanks,
Kai Uwe Broulik
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Default activity naming issues
Kevin Ahem... Sorry for the ramblings. :-) No need to apologize, sidetracking this theme to discuss nice things is not a crime :) I totally agree with the workflow you'd like to have (I'd like it as well :) ) Aaron If we want a meangingful default name At this time, until somebody brave enough introduces a first-run wizard again :), we don't need a meaningful name - just the name that will not lead to confusion. That is why I liked the 'Main activity' name (I'm using just 'Main' for stuff that don't belong to any activity). It is, in essence, as meaningful as untitled/new folder/new activity but should not lead to problems we now have: - link to main activity - switch to main activity is not bad. Martin what are you using your system primarily for? Martin * work Martin * videos Martin * Internet That would be quite nice - it could even create more than one activity. But, as I said, we'll need a solution for P1, and I don't think anyone will want to do this before P2. Cheerio! p.s. Thanks for the help on (for most of us) seemingly irrelevant things. :) -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 110413: Show in the tasks applet the activities a task is available on
On May 15, 2013, 1:43 p.m., Aaron J. Seigo wrote: Ship It! Commited in 2ac45a07d6f4d5732219677795d0d280d2549956 (In the commit message instead I made a mistake and use the keyword FEATURE instead of REVIEW, leaving BUG where it should be FEATURE :( ) - José --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110413/#review32563 --- On May 15, 2013, 9:03 a.m., José Millán Soto wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110413/ --- (Updated May 15, 2013, 9:03 a.m.) Review request for Plasma. Description --- This patch adds information about the activities on which a task is available to the tooltip. Two methods to obtain information about the activities a task is available, activities and activityNames, where added to TaskManager::TaskItem. Depending whether the applet is configured to show tasks which are not available in the current activity or not, the information displayed will be different. If the applet is configured to show only tasks in current activity, only the tasks which are also available in other activities will have this information in the tooltip. This addresses bug 307163. http://bugs.kde.org/show_bug.cgi?id=307163 Diffs - libs/taskmanager/taskitem.h 35606e2 libs/taskmanager/taskitem.cpp c9613c9 plasma/desktop/applets/tasks/windowtaskitem.cpp f840076 Diff: http://git.reviewboard.kde.org/r/110413/diff/ Testing --- In order to test this patch, three activities (called Activity 1, Activity 2 and Activity 3) were created. Various instances of KDialog were created, all of them in desktop 1, and they were assigned to various activities (The title of the dialog was set to AxDi, where x are the activities on which the dialog will be available). All screenshots were taken on activity 1. Screenshots 1 to 3 were taken with the taskbar configured to display tasks in all activities but only in desktop 1. Screenshots 4 to 6 were taken with the configuration to show tasks only in current activity. Screenshot 7 was taken with the taskbar displaying all tasks from all desktops. Screenshot 8 was created with the taskbar configured to group elements by program (activity information is not yet available). File Attachments Screenshot 1 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/13/snapshot1.png Screenshot 2 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/13/snapshot2.png Screenshot 3 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/13/snapshot3.png Screenshot 4 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/13/snapshot4.png Screenshot 5 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/13/snapshot5.png Screenshot 6 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/13/snapshot6.png Screenshot 7 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/13/snapshot7.png Screenshot 8 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/13/snapshot8.png Thanks, José Millán Soto ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 110413: Show in the tasks applet the activities a task is available on
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110413/ --- (Updated May 15, 2013, 4:04 p.m.) Status -- This change has been marked as submitted. Review request for Plasma. Description --- This patch adds information about the activities on which a task is available to the tooltip. Two methods to obtain information about the activities a task is available, activities and activityNames, where added to TaskManager::TaskItem. Depending whether the applet is configured to show tasks which are not available in the current activity or not, the information displayed will be different. If the applet is configured to show only tasks in current activity, only the tasks which are also available in other activities will have this information in the tooltip. This addresses bug 307163. http://bugs.kde.org/show_bug.cgi?id=307163 Diffs - libs/taskmanager/taskitem.h 35606e2 libs/taskmanager/taskitem.cpp c9613c9 plasma/desktop/applets/tasks/windowtaskitem.cpp f840076 Diff: http://git.reviewboard.kde.org/r/110413/diff/ Testing --- In order to test this patch, three activities (called Activity 1, Activity 2 and Activity 3) were created. Various instances of KDialog were created, all of them in desktop 1, and they were assigned to various activities (The title of the dialog was set to AxDi, where x are the activities on which the dialog will be available). All screenshots were taken on activity 1. Screenshots 1 to 3 were taken with the taskbar configured to display tasks in all activities but only in desktop 1. Screenshots 4 to 6 were taken with the configuration to show tasks only in current activity. Screenshot 7 was taken with the taskbar displaying all tasks from all desktops. Screenshot 8 was created with the taskbar configured to group elements by program (activity information is not yet available). File Attachments Screenshot 1 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/13/snapshot1.png Screenshot 2 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/13/snapshot2.png Screenshot 3 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/13/snapshot3.png Screenshot 4 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/13/snapshot4.png Screenshot 5 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/13/snapshot5.png Screenshot 6 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/13/snapshot6.png Screenshot 7 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/13/snapshot7.png Screenshot 8 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/13/snapshot8.png Thanks, José Millán Soto ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: PotD Headers
On Wed, May 15, 2013 at 3:50 AM, Martin Gräßlin mgraess...@kde.org wrote: On Wednesday 15 May 2013 08:40:06 Marco Martin wrote: that would make it a public library, with the promise of more quality and absolute binary stability that this brings.. would be fine,.. as long someone commits to maintain a library with such a promise (that would probably require some refactor to be ready, such as being all based on dpointers) as it's in kdeplasma-addons the binary stability should not matter as long as the so version is increased with each release. Well, let's backtrack a bit: do we want to make it easier for people to develop PotD providers? If so, then we need to take those decisions (who, how, when) in some order, and face the matter below: Still it would be against what we are used to have and I'm not sure whether our packagers would be happy about having kdeplasma-addons as a build dep. David E. Narvaez ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kde-workspace and plasma2
On Tuesday 14 May 2013, Aaron J. Seigo wrote: Even porting a few of the plasmoids wouldn't be the worst of ideas. (I expect the icon one to be interesting ...) Not everything needs to be ported right now, however, especially not components that get frequent activity. And what I really don't want to see is the whole repository turned upside down right now. Let's keep sebas' branch focused on a minimal set of ported components to test the new shell with. ok, so now that branch does build and the plasma subdirectory can build by itself having now a complete cmake the directory structure is as untouched as possible as everything outside the plasma subdirectory is untouched -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 110453: Order tasks by activity in tasks applet
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110453/ --- Review request for Plasma. Description --- A new ordering strategy ActivitySortingStrategy was created. This strategy will order elements by the activities they are available on. The ones which are available in the activities with more tasks will be displayed first. Diffs - libs/taskmanager/CMakeLists.txt 375a0d6 libs/taskmanager/groupmanager.h f7e9878 libs/taskmanager/groupmanager.cpp 45c15a9 libs/taskmanager/strategies/activitysortingstrategy.h PRE-CREATION libs/taskmanager/strategies/activitysortingstrategy.cpp PRE-CREATION plasma/desktop/applets/tasks/tasks.cpp 0a86dcf Diff: http://git.reviewboard.kde.org/r/110453/diff/ Testing --- Three activities were created (called Activity 1, 2 and 3), and several dialogs were created (the activities to which each dialog were assigned are marked by the numbers after the A in the title). Screenshot 1 shows the task manager running in plasma-windowed with grouping disabled, and the task manager being assigned to all activities. The second screenshot shows the task manager if the task manager is assigned only to Activity 1, an instance of xmessage is assigned to activity 2 and the grouping by program is active. File Attachments Screenshot 1 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/15/img1.png Screenshot 2 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/15/img2.png Thanks, José Millán Soto ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 110453: Order tasks by activity in tasks applet
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110453/#review32589 --- I'm aware that a new version of the tasks applet is being done in QML, but most of the changes are done in the library and not in the applet itself (the only change made to the applet is to add the ordering in the Order by combobox of the config dialog), so I think this patch can be applied even if the tasks applet is going to be replaced. - José Millán Soto On May 15, 2013, 5:34 p.m., José Millán Soto wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110453/ --- (Updated May 15, 2013, 5:34 p.m.) Review request for Plasma. Description --- A new ordering strategy ActivitySortingStrategy was created. This strategy will order elements by the activities they are available on. The ones which are available in the activities with more tasks will be displayed first. Diffs - libs/taskmanager/CMakeLists.txt 375a0d6 libs/taskmanager/groupmanager.h f7e9878 libs/taskmanager/groupmanager.cpp 45c15a9 libs/taskmanager/strategies/activitysortingstrategy.h PRE-CREATION libs/taskmanager/strategies/activitysortingstrategy.cpp PRE-CREATION plasma/desktop/applets/tasks/tasks.cpp 0a86dcf Diff: http://git.reviewboard.kde.org/r/110453/diff/ Testing --- Three activities were created (called Activity 1, 2 and 3), and several dialogs were created (the activities to which each dialog were assigned are marked by the numbers after the A in the title). Screenshot 1 shows the task manager running in plasma-windowed with grouping disabled, and the task manager being assigned to all activities. The second screenshot shows the task manager if the task manager is assigned only to Activity 1, an instance of xmessage is assigned to activity 2 and the grouping by program is active. File Attachments Screenshot 1 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/15/img1.png Screenshot 2 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/15/img2.png Thanks, José Millán Soto ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Using plasma enums from QML2
On Tuesday 14 May 2013, Aaron J. Seigo wrote: i think they should go In a perfect world, yes. In the less perfect world we live in, it means more porting work. Not sure which is worse. I suppose, at least, that this kind of porting can be done with a script. i think the branch is pretty much ready to go now -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Patch Review
Hi, With regard to the bug :: https://bugs.kde.org/show_bug.cgi?id=319626 , I have submitted a patch for review. Its a very minor change as per the idea suggestion by Shantanu. Please let me know if further changes are to be discussed :) I have simply removed the visible tag in the Plasma ToolButton under PlaylistDelegate.qml file which enables the playlist to have the remove sign on every song in the playlist. So now, user does not have to click on the song and then delete it from playlist which earlier forced PMC to stop the current media. Now the current media can be played on while removing/deleting any other item in the playlist of the mediaplayer. Cheers, Akshay Ratan On Mon, May 13, 2013 at 11:58 PM, Akshay Ratan akshayra...@gmail.comwrote: Hi, Thanks for the review . I am sorry, i didnt really ask before implementing the tooltip, I believe I should have done that. Anyways, in that case, Should I like implement the text feature at few necessary places in PMC ? I should be able to do that without much difficulty I presume with obviously a little help if necessary from Plasma Developers. And yes, its indeed an enjoyable period for me learning QML and other stuff ! :) Summers would no doubt be an exciting one for me :) Cheers, Akshay Ratan On Sun, May 12, 2013 at 10:40 PM, Sinny Kumari ksi...@gmail.com wrote: Hi! Good to see your progress :) getting error since there is no item named ToolTip. Did you forget to add any file like ToolTip.qml in diff ? One more thing, we don't want to keep tooltip in PMC, UI should be itself in such a way that it shouldn't require tooltip to understand. One reason for this is tooltip won't work on tablet and TV since tooltip work on mouse hover. Instead of tooltip, we will use the idea of having text at bottom for element in focus like you see in Home screen, the text description which come for selected backend. On Sun, May 12, 2013 at 2:31 AM, Akshay Ratan akshayra...@gmail.comwrote: Hi, Read and understood your previous mail very carefully. I thought to reply with a concerned patch regarding the animation problem in GridView. Anyways, as Shantanu and you suggested to study QML Animations and Transitions thoroughly, I was doing that :) Take your time to learn. There is no hurry. Don't think like you don't know much now. You will learn many things while working. I too learned in the same way and still learning :) Anyways, while going through the codebase, I thought to implement a tooltip for the Slideshow button in the Picture Gallery. Also in the PictureStrip.qml , minor code editing has been tried by me. The resultant, rather a little messy code patch is attached. Please review it ! Kompare is providing a good view of the differences :) Its a very basic patch :( I am trying to do better by studying QML as promised thoroughly ! I should be able to master it in a few days. As Shantanu suggested, I am in a process of making a GridView based viewer and then testing for the transition smoothness in it. To be honest, its complete fun hacking on PMC :) I will CC the patch for the community review once its in a perfect shape and better after your suggestions ! Thanks for the help ! Cheers, Akshay Ratan -- http://www.sinny.in -- Akshay -- Akshay ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 110453: Order tasks by activity in tasks applet
On May 15, 2013, 5:36 p.m., José Millán Soto wrote: I'm aware that a new version of the tasks applet is being done in QML, but most of the changes are done in the library and not in the applet itself (the only change made to the applet is to add the ordering in the Order by combobox of the config dialog), so I think this patch can be applied even if the tasks applet is going to be replaced. The QML version does indeed still rely on the sorting strategies implemented in the library, so this patch is fairly low-impact as far as the QML port is concerned. - Eike --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110453/#review32589 --- On May 15, 2013, 5:34 p.m., José Millán Soto wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110453/ --- (Updated May 15, 2013, 5:34 p.m.) Review request for Plasma. Description --- A new ordering strategy ActivitySortingStrategy was created. This strategy will order elements by the activities they are available on. The ones which are available in the activities with more tasks will be displayed first. Diffs - libs/taskmanager/CMakeLists.txt 375a0d6 libs/taskmanager/groupmanager.h f7e9878 libs/taskmanager/groupmanager.cpp 45c15a9 libs/taskmanager/strategies/activitysortingstrategy.h PRE-CREATION libs/taskmanager/strategies/activitysortingstrategy.cpp PRE-CREATION plasma/desktop/applets/tasks/tasks.cpp 0a86dcf Diff: http://git.reviewboard.kde.org/r/110453/diff/ Testing --- Three activities were created (called Activity 1, 2 and 3), and several dialogs were created (the activities to which each dialog were assigned are marked by the numbers after the A in the title). Screenshot 1 shows the task manager running in plasma-windowed with grouping disabled, and the task manager being assigned to all activities. The second screenshot shows the task manager if the task manager is assigned only to Activity 1, an instance of xmessage is assigned to activity 2 and the grouping by program is active. File Attachments Screenshot 1 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/15/img1.png Screenshot 2 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/15/img2.png Thanks, José Millán Soto ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Patch Review
On Wednesday 15 May 2013, Akshay Ratan wrote: Hi, With regard to the bug :: https://bugs.kde.org/show_bug.cgi?id=319626 , I have submitted a patch for review. Its a very minor change as per the idea suggestion by Shantanu. Please let me know if further changes are to be discussed :) Hi, first of all thanks for the patch :) one problem of putting it on bugzilla is that they risk to get forgotten. Since we had this problem in the past, now a new system for patches is in place: https://git.reviewboard.kde.org makes commenting on single patch lines way easier Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Patch Review
Cool! patch works fine :) On Thu, May 16, 2013 at 2:17 AM, Marco Martin notm...@gmail.com wrote: On Wednesday 15 May 2013, Akshay Ratan wrote: Hi, With regard to the bug :: https://bugs.kde.org/show_bug.cgi?id=319626 , I have submitted a patch for review. Its a very minor change as per the idea suggestion by Shantanu. Please let me know if further changes are to be discussed :) Hi, first of all thanks for the patch :) one problem of putting it on bugzilla is that they risk to get forgotten. Since we had this problem in the past, now a new system for patches is in place: https://git.reviewboard.kde.org + 1 One more thing, patch attached on bugzilla contains some extra diff from your build directory. Please fix that and then send it on reviewboard :) Cheers! -- http://www.sinny.in ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
