Re: Reshuffling startup to start activity manager after ksmserver
I would say that the right thing (what I as a user would expect to happen) is that clicking save session in the kickoff menu would save which I might be missing the point - kamd loads the last used activity on login (if it doesn't, it is a bug). What would change if we saved at 'save session'? Cheerio, Ivan -- Make your code readable. Pretend the next person who looks at your code is a psychopath and they know where you live. -- Philip Wadler 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: Reshuffling startup to start activity manager after ksmserver
On Sunday, May 26, 2013 1:23:20 PM ICT, Ivan Čukić wrote: I would say that the right thing (what I as a user would expect to happen) is that clicking save session in the kickoff menu would save which I might be missing the point - kamd loads the last used activity on login (if it doesn't, it is a bug). What would change if we saved at 'save session'? Hello Ivan, yes you did. The point is that when setting restore manually saved session as the login behavior (setting for ksmserver) then the save session button appears in kickoff and only what was running at the time you click that button should then get started at all future logins. The needed change for this to work would be for kamd to _not_ save the running state to file every time it changes, but instead only when asked by the session manager to save state. (For applications that is done by overriding the implementation of QApplication::saveState() or by using KSessionManager) Cheerio, Ivan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Reshuffling startup to start activity manager after ksmserver
On Sunday 26 May 2013 14:30:05 Simon Persson wrote: The needed change for this to work would be for kamd to _not_ save the running state to file every time it changes, but instead only when asked by the session manager to save state. (For applications that is done by overriding the implementation of QApplication::saveState() or by using KSessionManager) that would require more user interaction to get it right? seems to complicate things for users and developers.. -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Reshuffling startup to start activity manager after ksmserver
overriding the implementation of QApplication::saveState() or by using KSessionManager) Ah, ok then. You have the green light for the change, as long as it doesn't changes the workflow for the non-manually-saved-session-restoration mode. Cheerio, Ivan -- A program that has not been tested does not work. -- Bjarne Stroustrup ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 110608: Add support for keyboard backlight handling to the powermanagement dataengine
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110608/#review33143 --- Ship it! Ship It! - Marco Martin On May 23, 2013, 9:13 a.m., Kai Uwe Broulik wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110608/ --- (Updated May 23, 2013, 9:13 a.m.) Review request for Plasma and Solid. Description --- This patch adds support for keyboard backlight handling to the powermanagement dataengine. It is similar to the backlight handling. Allows setting and getting they keyboard brightness and checking whether it is supported at all. Diffs - plasma/generic/dataengines/powermanagement/powermanagementengine.h 319a17c plasma/generic/dataengines/powermanagement/powermanagementengine.cpp 4b184fa plasma/generic/dataengines/powermanagement/powermanagementjob.h 3b974ab plasma/generic/dataengines/powermanagement/powermanagementjob.cpp 6f90006 plasma/generic/dataengines/powermanagement/powermanagementservice.operations 533c00a Diff: http://git.reviewboard.kde.org/r/110608/diff/ Testing --- Adjusting keyboard brightness from the battery monitor so col. Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 110608: Add support for keyboard backlight handling to the powermanagement dataengine
On May 26, 2013, 9:39 a.m., Marco Martin wrote: Ship It! At least for the plasma part, some feedback by solid people would be appreciated as well ;) - Marco --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110608/#review33143 --- On May 23, 2013, 9:13 a.m., Kai Uwe Broulik wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110608/ --- (Updated May 23, 2013, 9:13 a.m.) Review request for Plasma and Solid. Description --- This patch adds support for keyboard backlight handling to the powermanagement dataengine. It is similar to the backlight handling. Allows setting and getting they keyboard brightness and checking whether it is supported at all. Diffs - plasma/generic/dataengines/powermanagement/powermanagementengine.h 319a17c plasma/generic/dataengines/powermanagement/powermanagementengine.cpp 4b184fa plasma/generic/dataengines/powermanagement/powermanagementjob.h 3b974ab plasma/generic/dataengines/powermanagement/powermanagementjob.cpp 6f90006 plasma/generic/dataengines/powermanagement/powermanagementservice.operations 533c00a Diff: http://git.reviewboard.kde.org/r/110608/diff/ Testing --- Adjusting keyboard brightness from the battery monitor so col. Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 110504: Group tasks by activity
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110504/#review33145 --- The libtaskmanager part is nice. However the applet is about t be replaced, so the display part would have to be redone - Marco Martin On May 18, 2013, 2:13 p.m., José Millán Soto wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110504/ --- (Updated May 18, 2013, 2:13 p.m.) Review request for Plasma. Description --- New grouping strategy was created to allow tasks to be grouped by activity. If an item is available in multiple activities, it will only appear in one of the activities the task is available on (except if it's available on all activities). GroupManager was modified so that whether items should be grouped just when the task bar is full or not is not only taken into account when grouping by program but also when grouping by activity. Activity icons are not handled yet, so an icon from the first task which was on the group is used as the icon of the task group. Diffs - plasma/desktop/applets/tasks/tasks.cpp dbbb0cb libs/taskmanager/strategies/activitygroupingstrategy.cpp PRE-CREATION libs/taskmanager/groupmanager.cpp 9ac15e7 libs/taskmanager/strategies/activitygroupingstrategy.h PRE-CREATION libs/taskmanager/CMakeLists.txt 70fa791 libs/taskmanager/groupmanager.h ad4167a Diff: http://git.reviewboard.kde.org/r/110504/diff/ Testing --- Three activities were created (named Activity 1, Activity 2 and Activity 3). One instance of KDialog was assigned to Activity 1, two instances of KDialog were assigned to Activity 2, three instances of KDialog were assigned to Activity 3 and one instance of KDialog was assigned both to Activities 2 3. The tasks applet was executed in plasma-windowed in all activities. Screenshot 1 2 show the task manager in the situation described above. Screenshot 3 shows the same task manager after leaving only one instance of KDialog in each activity (Only group when taskbar is full enabled), and screenshot 4 shows the task manager when the tasks are the same that in screenshot 3 but Only group when taskbar is full is disabled. File Attachments Screenshot 1 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/18/img1.png Screenshot 2 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/18/img2.png Screenshot 3 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/18/img3.png Screenshot 4 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/18/img4.png Thanks, José Millán Soto ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[RFC] Disable bug reporting till Bugzilla situation is improved
Hi all, this is probably a controversial proposal: Let's disable bug reporting for Plasma until the current situation is improved. Reason: the bugtracker in it's current state gets flooded by new incoming reports and we are not able to get the water out of our cellar as long as new water is coming in. So let's put a plug into the leaking pipe and then start to get the water out and let's fix the leak properly and then turn on the water again. I don't know whether it's possible (need to talk to sysadmins), but I would keep it open for kde devs, so that we would get reports for newly introduced regressions/bugs in master. This has to be absolutely temporarily and should be stopped before the release of 4.11. If I had to set a hard date I would say June, 26th, which is the beta 2 release. Opinions? Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [RFC] Disable bug reporting till Bugzilla situation is improved
On Sunday, May 26, 2013 12:05:25 Martin Graesslin wrote: this is probably a controversial proposal: Let's disable bug reporting for Plasma until the current situation is improved. .. Opinions? I would expect this to piss off users even more than the current situation. Saying we don't even want your input is one step worse than add your input, it may not be immediately addressed. It will also teach people not to try and we'll lose future reports. So -1 from me .. -- 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 107983: Fix KWindowSystem::compositingChanged signal
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107983/#review33146 --- Ship it! Ship It! - Aaron J. Seigo On March 23, 2013, 8:06 p.m., Thomas Lübking wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107983/ --- (Updated March 23, 2013, 8:06 p.m.) Review request for kdelibs, kwin, Plasma, Aaron J. Seigo, Fredrik Höglund, Martin Gräßlin, and Marco Martin. Description --- It works fine here (tested so far KWindowSystem signal, KSelectionWatcher only with kwin) with kwin (shift+alt+f12), xcompmgr, compiz metacity -c and e17. Didn't try xfce nor mutter. Technically: I do not at all understand why KWindowSystem is *not* watching the root window - KSelectionOwner for one is sending events to the root and this also seems the case for all other WMs (at least everything now starts to cause the signal to be emitted) The KSelectionWatcher failure seems to be kwin specific (wrote me a cleaner testcase), there'll be some X11 event processing on top that eats away the client messages. So this one can be scratched from the patch, the KWindowSystem issue remains. This addresses bug 179042. http://bugs.kde.org/show_bug.cgi?id=179042 Diffs - kdeui/windowmanagement/kwindowsystem_x11.cpp f9b3cc1 Diff: http://git.reviewboard.kde.org/r/107983/diff/ Testing --- see summary File Attachments testcase http://git.reviewboard.kde.org/media/uploaded/files/2013/01/04/selectionwatcher.cpp Thanks, Thomas Lübking ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [RFC] Disable bug reporting till Bugzilla situation is improved
On Sunday 26 May 2013 13:26:45 Aaron J. Seigo wrote: On Sunday, May 26, 2013 12:05:25 Martin Graesslin wrote: this is probably a controversial proposal: Let's disable bug reporting for Plasma until the current situation is improved. .. Opinions? I would expect this to piss off users even more than the current situation. Saying we don't even want your input is one step worse than add your input, it may not be immediately addressed. It will also teach people not to try and we'll lose future reports. If we would sell it as part of a quality offensive... ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 110504: Group tasks by activity
On May 26, 2013, 9:42 a.m., Marco Martin wrote: The libtaskmanager part is nice. However the applet is about t be replaced, so the display part would have to be redone I am aware that the tasks applet is going to be replaced soon, but most changes of this patch are in the library and not in the applet. I don't mind creating a patch for the new version of the applet to handle this grouping once the new version of the applet is available. - José --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110504/#review33145 --- On May 18, 2013, 2:13 p.m., José Millán Soto wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110504/ --- (Updated May 18, 2013, 2:13 p.m.) Review request for Plasma. Description --- New grouping strategy was created to allow tasks to be grouped by activity. If an item is available in multiple activities, it will only appear in one of the activities the task is available on (except if it's available on all activities). GroupManager was modified so that whether items should be grouped just when the task bar is full or not is not only taken into account when grouping by program but also when grouping by activity. Activity icons are not handled yet, so an icon from the first task which was on the group is used as the icon of the task group. Diffs - plasma/desktop/applets/tasks/tasks.cpp dbbb0cb libs/taskmanager/strategies/activitygroupingstrategy.cpp PRE-CREATION libs/taskmanager/groupmanager.cpp 9ac15e7 libs/taskmanager/strategies/activitygroupingstrategy.h PRE-CREATION libs/taskmanager/CMakeLists.txt 70fa791 libs/taskmanager/groupmanager.h ad4167a Diff: http://git.reviewboard.kde.org/r/110504/diff/ Testing --- Three activities were created (named Activity 1, Activity 2 and Activity 3). One instance of KDialog was assigned to Activity 1, two instances of KDialog were assigned to Activity 2, three instances of KDialog were assigned to Activity 3 and one instance of KDialog was assigned both to Activities 2 3. The tasks applet was executed in plasma-windowed in all activities. Screenshot 1 2 show the task manager in the situation described above. Screenshot 3 shows the same task manager after leaving only one instance of KDialog in each activity (Only group when taskbar is full enabled), and screenshot 4 shows the task manager when the tasks are the same that in screenshot 3 but Only group when taskbar is full is disabled. File Attachments Screenshot 1 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/18/img1.png Screenshot 2 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/18/img2.png Screenshot 3 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/18/img3.png Screenshot 4 http://git.reviewboard.kde.org/media/uploaded/files/2013/05/18/img4.png Thanks, José Millán Soto ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Switches around the world and broken metaphors [Was: Battery Monitor revamp]
On Sunday 26 May 2013 00:05:56 Marco Martin wrote: On Saturday 25 May 2013 14:32:29 Martin Graesslin wrote: And this is clearly the case let's work around something we don't want to fix. Switches are a clear improvement over checkboxes depending on the context even my 60yo mom got it much quickier than a checkbox would be able to on my plasmoids. And I would completely fail to use the switch. I have huge problems understanding those switches and I have not seen any implementation of the switch where I got which one is on and which one is off. that's for me as well. I have to spend a second or more every time to figure/remember if the on that is written on the switch (or being colored vs greyed, same thing) means it's on now or it's an action, so it's telling me it becomes on if i click on it Well actually, there is an easy way to make it absolutely clear which is which, although it takes lots of horizontal space and probably looks very ugly if you have many switches in the same UI: Just add text labels on each side, _next to_ the button, not inside of it. E.g. OFF or O on the left side, ON or I on the right side. That makes things perfectly clear. So if ambiguity is the only reason against using switches on Desktop, we should use them. If you can make it clear on a touch screen, you can make it clear on a normal monitor. However, there may be more reasons than that. Let us look at the issue more closely. First of all, switches are _not_ merely the touch version of checkboxes. Some developers may use them that way, but they are not. They should be used for different purposes, and the GUI guidelines of systems that have both do make that clear (though interestingly, the decision criterion varies from platform to platform: - The Android design guidelines make the following distinction: Checkboxes allow the user to select multiple options from a set. Avoid using a single checkbox to turn an option off or on. Instead, use an on/off switch.[1] - The guidelines for BB10 go in a similar direction[2]: Use check boxes when users can select multiple items or options. Use a toggle switch when users are choosing between two distinct options, such as Off and On. You can also use a toggle switch if you want to make a setting harder for users to change accidentally. So according to the Android or Blackberry guidelines, the Battery Monitor should use a switch, whereas the Printer Manager should use checkboxes. - The Meego UX guidelines[3] (yes, Meego is dead but that doesn't mean their guidelines are bad) say the following: Toggle switches are best used in system or applications settings, and are best suited to toggle a setting or mode that affects the whole system. Good examples are switching networking or silent mode on or off. A checkbox works in the same way as a toggle switch, but it is more suitable to use for smaller settings, like a preference in an application So these guidelines would speak for using a switch in the Battery Monitor as well. Regarding the Printer Manager, it would be a question of interpretation. - The Windows Store apps guidelines[4] offer a distinction which I personally find the most logical: Use a toggle switch for binary settings when changes become effective immediately after the user changes them. Use a checkbox when the user has to perform extra steps for changes to be effective. For example, if the user must click a submit or next button to apply changes, use a check box. The reason why I find this logical is that it relates to the real-world equivalent of checkboxes and switches. When I flick a switch, usually something happens immediately. On the other hand, checking a box on a paper form does not immediately change anything, it only has an effect after I _submitted_ the form somewhere. And this is similar in the digital world: Checkboxes first appeared on digital forms, where changes only went into effect after the form was submitted. Therefore if we only use checkboxes for changes without immediate effect, users can be sure that changing the state of a checkbox won't do any immediate harm. According to these guidelines, both Battery Monitor and Printer Manager would use switches. So conceptually there is indeed a difference between a checkbox and a switch. Now, with that said, comes the big but: All of these guidelines are for touch-based OSes. Looking at the guidelines for mouse/keyboard systems from the same vendors reveals a different picture. Neither the OS X Human Interface Guidelines[5], nor the GNOME Human Interface Guidelines[6] (Toggle Buttons are not the same as switches!), the Microsoft guidelines for desktop applications[7] or the ChomiumOS guidelines[8] contain any mention of switches. They all have only check boxes. So why is that so, even though the criteria for using switches instead of checkboxes would apply in the desktop world as well? Unless someone here knows someone in the
Re: Switches around the world and broken metaphors [Was: Battery Monitor revamp]
On Sunday 26 May 2013 18:07:14 Thomas Pfeiffer wrote: On Sunday 26 May 2013 00:05:56 Marco Martin wrote: On Saturday 25 May 2013 14:32:29 Martin Graesslin wrote: And this is clearly the case let's work around something we don't want to fix. Switches are a clear improvement over checkboxes depending on the context even my 60yo mom got it much quickier than a checkbox would be able to on my plasmoids. And I would completely fail to use the switch. I have huge problems understanding those switches and I have not seen any implementation of the switch where I got which one is on and which one is off. that's for me as well. I have to spend a second or more every time to figure/remember if the on that is written on the switch (or being colored vs greyed, same thing) means it's on now or it's an action, so it's telling me it becomes on if i click on it Well actually, there is an easy way to make it absolutely clear which is which, although it takes lots of horizontal space and probably looks very ugly if you have many switches in the same UI: Just add text labels on each side, _next to_ the button, not inside of it. E.g. OFF or O on the left side, ON or I on the right side. That makes things perfectly clear. Yes, it does. That clearly would work for me. As I mentioned in one of the replies if I see both states with a label, I am able to recognize what means on and what means off. As mentioned I found exactly one switch similar to the touch switches in my flat and it has distinct labels and I never failed to use that one ;-) So if ambiguity is the only reason against using switches on Desktop, we should use them. At least for me there is another reason: given the way how the switch component is designed (again no matter which one) I am inclined to drag it from left to right. I don't try to click, I have to drag. There is no visual hint that clicking would adjust the state. It doesn't look like a clickable button. This makes the component really difficult to use. While on a touch screen it's much easier to use than a check box. Now I could learn to click (so far I failed to do so), but I can think of many people who would no longer be able to learn this. Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [RFC] Disable bug reporting till Bugzilla situation is improved
于 2013年05月26日 18:05, Martin Graesslin 写道: Hi all, this is probably a controversial proposal: Let's disable bug reporting for Plasma until the current situation is improved. Reason: the bugtracker in it's current state gets flooded by new incoming reports and we are not able to get the water out of our cellar as long as new water is coming in. So let's put a plug into the leaking pipe and then start to get the water out and let's fix the leak properly and then turn on the water again. I don't know whether it's possible (need to talk to sysadmins), but I would keep it open for kde devs, so that we would get reports for newly introduced regressions/bugs in master. This has to be absolutely temporarily and should be stopped before the release of 4.11. If I had to set a hard date I would say June, 26th, which is the beta 2 release. Opinions? Cheers Martin Hi, I think this is surely better than let's acknowledge the mess, close all existing bugs and restart from zero. But still I think it is a dangerous action which might cause anger, flames and rants. What about organizing a plasma bug days(or weeks) as usual (when was the last one?), then announce and apply that no new bugs any more as a temporary policy only for and during that organized event ? My point is not accepting new bugs is so easy to be misinterpreted by the users and press. Let's cover it up with a better name. Regards Jekyll ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [RFC] Disable bug reporting till Bugzilla situation is improved
On Monday, May 27, 2013 00:41:31 Jekyll Wu wrote: let's acknowledge the mess, close all existing bugs and restart from zero. afaik, that is not being suggested. the plan is close OLD crash reports so we only have crash reports against moderately new versions. -- 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: Battery Monitor revamp
So I pushed a few patches: Am Samstag, 25. Mai 2013, 13:10:14 schrieb Aaron J. Seigo: see these screenshots for some layouting issues: Fixed. also, after expanding a battery to see detailed information, collapsing it leaves an empty space. that should re-collapse, similar to thow the notifications plasmoid does. Hmm, not sure how I can do that. When I play around with the minimum size of the plasmoid, it often just ends up puking its content to the panel and not becoming a popup applet. also, would be nice to align the content in the tooltip with a (i know, horrible:) html table. we do this elsewhere and it looks a lot nicer. Done. I removed the AC adapter thing from the tooltip as well. I wanted to make the percentage bold but it looks misaligned with oxygen font (which it does in the current battery monitor too) The icon on the left also reflects the battery status. very nice; one thing that Marco noted was that it should only be animating when the popup is open Fixed. Although I couldnt just do running: plasmoid.popupShowing but had to fetch the property on the root item and pass it through to the BatteryItem to me, the easing curve also seems a bit .. not right. after changing the InQuad to InCubic in BatteryItem.qml line 117 it feels a lot more like it is charging. Agreed. Fixed. fine with me. as i've noted numerous times before, remaining time is inherently innacurate. it is only accurate over long periods of (statistically) consistent power draw. in a modern system, that is generally not the case. one visit to youtube can ruin your expectations ;) Completely removed now. All helper functions, properties, etc. The Dataengine still exposes it but we should leave it there, so an upset user could add it back or third party battery monitors that might appear on kde-apps don't break. so we'd vote for leaving them out. Also completely removed. Also removed the platformcontents folder because the only thing in there was the platform.js that was helping for suspend. we'd also vote for getting rid of the option to show the percentage overlay on the battery icon. it could be shown on desktop when the plasmoid gets to a certain size, and instead of floating in the middle of the battery (which looks not so nice) it could perhaps appear in a small strip that overlays the battery across the full width at the very bottom? On the desktop it would work that way, yes. But I really want to have the percentage shown in the panel but don't know how that could work better like the curent implementation. If there wasn't that blockish look but a continuous rectangle we could more accurately reflect the percentage. the problem is in powerdevil? Wrote a mail to kde-hardware-devel about that. Switches Replaced with a checkbox and tried to make the best of it… ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Switches around the world and broken metaphors [Was: Battery Monitor revamp]
On Sunday 26 May 2013 18:35:20 Martin Graesslin wrote: So if ambiguity is the only reason against using switches on Desktop, we should use them. At least for me there is another reason: given the way how the switch component is designed (again no matter which one) I am inclined to drag it from left to right. I don't try to click, I have to drag. There is no visual hint that clicking would adjust the state. It doesn't look like a clickable button. This makes the component really difficult to use. While on a touch screen it's much easier to use than a check box. Absolutely. This is what I meant by One reason is surely that flicking a switch on a touch screen, though not natural at all because of the lack of haptical feedback, is much closer to reality than flicking a switch by clicking it with a mouse. way further down in my mail ;) Now I could learn to click (so far I failed to do so), but I can think of many people who would no longer be able to learn this. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Battery Monitor revamp
On Sunday 26 May 2013 18:53:24 Kai Uwe Broulik wrote: very nice; one thing that Marco noted was that it should only be animating when the popup is open Fixed. Although I couldnt just do running: plasmoid.popupShowing but had to fetch the property on the root item and pass it through to the BatteryItem iirc property bindings from plasmoids don't work but you can put a Connections element on plasmoid and you can catch signals from it, is a limitation that needs plasma2 to be solved sadly Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [RFC] Disable bug reporting till Bugzilla situation is improved
On Sun, May 26, 2013 at 11:05 AM, Martin Graesslin mgraess...@kde.org wrote: Hi all, this is probably a controversial proposal: Let's disable bug reporting for Plasma until the current situation is improved. Reason: the bugtracker in it's current state gets flooded by new incoming reports and we are not able to get the water out of our cellar as long as new water is coming in. So let's put a plug into the leaking pipe and then start to get the water out and let's fix the leak properly and then turn on the water again. I don't know whether it's possible (need to talk to sysadmins), but I would keep it open for kde devs, so that we would get reports for newly introduced regressions/bugs in master. This has to be absolutely temporarily and should be stopped before the release of 4.11. If I had to set a hard date I would say June, 26th, which is the beta 2 release. To put in some real numbers, that's closing bugzilla for 30 days. On average Plasma currently gets 4.8 bugs and 0.4 wishlist reports a day [1] Based on this, closing bugzilla will save us having to deal with ~ 17 reports. From that, my opinion would be that it's more trouble than it's worth. David [1] https://bugs.kde.org/weekly-bug-summary.cgi?tops=50days=100 opened column divided by 100 at time of writing. Opinions? Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
