Re: The future of Power Management - together with Activities
On Sunday 2 October 2011 02:27:06 Kevin Kofler wrote: > I personally also don't use custom power management profiles, but to me, > tying this to Plasma activities (which I don't use and am certainly not > alone in not using) sounds very wrong. I find amazing how people can manage to have a strong opinion about two features they don't use. :-) Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron 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: ScreenSaver and KDE Plasma 4.8?
Luca Beltrame wrote: > After all, in the KDE Forums we don't see anymore people lamenting the > lack of icons on desktop by default... Probably because the distros are not shipping 4.7 yet. (4.1 to 4.6 actually do show desktop icons by default, in a folder view widget which is set up by default.) Or because users upgrading from a previous version of Plasma get to keep their folder view, and those are the ones already testing 4.7. Or maybe because the distros are now overriding this broken 4.7 default, as Fedora is now doing for Fedora 16 (as of kde-settings-4.7-7.fc16). (We restore the good old folder view widget, otherwise people won't even see an icon to install their live CD to the hard disk: https://bugzilla.redhat.com/show_bug.cgi?id=740676 . Note that this fix is actually not yet in F16 Beta, it will be in F16 Final. And any complaints about us actually using the JavaScript-based customization feature Plasma explicitly offers for distributions to use will be sent straight to /dev/null…) I'm fairly sure that when the first major distro starts shipping with 4.7 without a custom Plasma init script enabling the folder view of ~/Desktop one way or the other (either as a widget as in 4.6 or in Fedora 16, or the KDE-3-style "folder view as desktop" mode), complaints will start popping in in droves. Kevin Kofler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The future of Power Management - together with Activities
Dario Freddi wrote: > we plan to remove the "Warning" step Uhm, wait a minute… Do you mean you will just suspend or shut down the machine with no warning whatsoever? If that's really what you mean, to me, this sounds incredibly rude and might lead to data loss – especially if "shut down" is the chosen option, but even suspending or hibernating can be fatal, e.g. for online games (and yes, there's now wireless Internet, whereas wireless power has yet to be invented, at least one which works at a distance of more than a couple cm ;-) ), or if a kernel bug is breaking the suspending. So far all the discussion has focused on the "activities" thing, but if you really mean what I think you mean, this issue is even more important. We MUST give the user a chance to save his/her work and/or to plug the power in before we trigger a shutdown or suspend. Kevin Kofler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The future of Power Management - together with Activities
Andras Mantia wrote: > I don't like if software forces me to work in a certain way. And with > activities I'm not alone. I'm happy without them, even if they are useful > for others. Just as I'm mostly happy also without virtual desktops (which > are a must for others). People are different, they have different > workflows that they don't want to change if there is no *good* reason to > do it. [snip] > Please, keep this option. Having a way to control the power magament > setting per activity is fine, but leave the possibility to change (and > configure) the settings without having to use activities. +1 I personally also don't use custom power management profiles, but to me, tying this to Plasma activities (which I don't use and am certainly not alone in not using) sounds very wrong. Plasma activities affect many more things than just power management. Kevin Kofler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The future of Power Management - together with Activities
On Saturday 01 October 2011 23:41:42 Anders Lund wrote: > On Lørdag den 1. oktober 2011, Scott Kitterman wrote: > > I don't understand how creating a new activity represents an improvement > > to the user. If I understand the proposal correctly the user will only > > use the power manager to change existing profiles and if they want to > > create an alternative profile they will have to us something that is not > > the power manager. > > I have a usecase that illustratess it: I created a power management profile > for using on my boat, where low power consumption goes with staying up as > long as possible. To accomplish that, I also created an activity which > have no networkdependent plasmoids or applications running (or anything > resourcehungry, except for relevant stuff) > > With the proposed system, they will be naturally paired, which is very > nice. Thanks for explaining. You also remembered me that activities can also be used to save power, as you can pause apps/plasmoids (which are the real resource- hungry things). This is a nice side effect and another good reason towards using this approach. -- --- Dario Freddi KDE Developer GPG Key Signature: 511A9A3B 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: The future of Power Management - together with Activities
On Saturday 01 October 2011 21:30:02 Lukas wrote: > On 1 October 2011 21:36, wrote: > > > Something like having Power mode switch: > > > > > > [Performance] [Normal] [Battery stretch] > > > > > > where Normal is current static profile; Performance - temporary > > > disables any limitations; Battery stretch - disables everything, that > > > can be disabled [Wifi, audio, CPU turbo mode etc] > > > > This is actually why we thought about pairing profiles and activities. > > Although your concern is valid, you are likely to require this kind of > > things > > when doing a specific activity, hence you won't need the applet :) On the > > other hand, inhibition might be useful everywhere. > > Not exactly. Those switches was intended to be only temporary changes. So are activities. > > Lets say you are on the trip on the train using "Plasma development" > activity. Usually, all your development activities are set to average power > usage profile, but since the journey is long, and you are not listening to > music, nor using wifi [Battery stretch] could give you e.g +25% of battery > time. That's a dream-world assumption (like the 25% which pardon me, but it's slightly random). First of all, you can turn off your wi-fi through an hardware switch, which is usually what people do (although, if in the future powerdevil will be able to do that, great). Second, then how you define a "battery stretch?" You would need a dozen of those states to cover all corner cases. > > Other situation, you are giving a presentation on how to make a best of QT, > that requires compiling using the same using "Plasma development" > activity. Performance mode could at the same time disable any screensaver, > as well give green light to use all CPU power, ignoring the battery usage. And that's why the applet is now able to inhibit. CPU is not affected by profiles. > > Both are quite unusual but possible situations, but creating new activity > and moving all files/settings does not pay off. But in both cases, you don't need a separate profile/mode. We thought about much worse corner cases while discussing, and we still need to figure out one which explicitly needs a new profile. > > Also [Performance] and [Battery stretch] power modes could do more by e.g. > preventing any daemons (nepomuk, akonadi, owncloud) from staring background > works - a common complaint, that KDE semantic services starts at a very bad > time and there is no way to prevent them. That's indeed to be fixed inside those daemons - if we were to start thinking like this, KDE would be the land of workarounds. > > Cheers, > > Lukas -- --- Dario Freddi KDE Developer GPG Key Signature: 511A9A3B 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: The future of Power Management - together with Activities
On Saturday 01 October 2011 21:21:40 Andras Mantia wrote: > [Please reply on both lists if you cross-posted, otherwise dicussion will > be more fragmented. I just looked up the plasma list out of curiosity, > normally I don't follow, so your mail would have been missed.] > > Dario Freddi wrote: > >> I can't comment on activities, never used them, nor feel the need to use > >> them. So this sounds more like the power management applet would force > >> me to create and use activites. > > > > Well, if you like to see it that way, yes. Or better, we are trying to > > drive forward the concept of "one environment, one setting", where > > depending on what you do, the system is going to adapt. > > I don't like if software forces me to work in a certain way. And with > activities I'm not alone. I'm happy without them, even if they are useful > for others. Just as I'm mostly happy also without virtual desktops (which > are a must for others). People are different, they have different workflows > that they don't want to change if there is no *good* reason to do it. Sorry, but software forces you to work in certain ways everytime - it's just that you don't like how it's being laid down atm. Previously, you had to create a profile, I could have argued that I don't like a software which forces me to work in a certain way (profiles). I agree on the fact that people are different, but a huge percentage of them is not needing to change a profile manually, so delivering such a possibility in the only place where it might make sense is the rationale behind this idea. > > > There is still a rationale behind that. If you are in a situation where > > you are actually *using* your PC, the only setting available (at the > > moment) which is going to affect your battery life is brightness - > > everything else is depending on the idle time, and in an emergency > > situation one would simply close the lid and suspend straight away. > > Is it? Certainly disabling desktop effects and 3D acceleration has an > impact. Sorry to disappoint you, but this action will be removed in 4.8. Martin has explicitely stated that for how compositing in KDE works now turning off compositing is actually going to harm your battery instead of saving it - feel free to get in touch with him to expand on this topic, which is not exactly relevant to this discussion. > And there are other things like when to suspend automatically (if > do it at all), when to dim the display, etc. I agree, but are you sure you need to configure these things separately depending on where you are? If you are, say, working on a train, you're very likely to never be idle, and to suspend the PC on your own by closing the lid when not active to save the most power. How can a different profile help you here? > I remember some time ago > there was also a possibility to set how fast a CPU would run or throttle > down a CPU manually, but I can't see anything like that in the current > applet. Nowadays the ondemand governor handles that properly, feel free to search these lists or b.k.o for flames/discussions about it. > So I think there are more settings then display brightness (that > you usually can control anyway with an Fn shortcut on laptops). Again, as I said before, I am pretty sure there are no settings except brightness which require you to change to a different profile - in fact, there is a reason why brightness handling works this way at the moment. > If we only talk about the above, and my development example (e.g travelling > in an airplane): I know my travel takes 1 hour, my battery can last 2 > hours, so I want to use the laptop just as plugged into the wall. I start > it, but then it becomes clear there is a delay, so I need to save battery > life. Right now I just select a new profile, everything else remains the > same on the desktop. And what does it change? Yeah, brightness. You are working, and you'll never be idle. It might give you the illusion you are saving more energy, but I'd urge you to try lowering brightness and leave the profile unaltered - you might be surprised. > Why would I need to switch to a new activity in such > case? My work will be the same, just the conditions change. > Or while developing I realize I compile more often then needed and this > takes more power. So I need to save power in other way, again this would be > possible with a simple change in the applet. Which settings configurable from KDE's power manager are exactly affecting your battery besides brightness in this case? > Please, keep this option. Having a way to control the power magament > setting per activity is fine, but leave the possibility to change (and > configure) the settings without having to use activities Provided some good reasons, I will. But I think atm you are wasting your time creating new profiles, while you could achieve the same by tweaking your brightness. This kind of placebo-effect of switching to a profile with a
Re: The future of Power Management - together with Activities
On Saturday 01 October 2011 21:03:10 Andreas Pakulat wrote: > What happens if I don't use activities at all since they provide no use > for me? And whats also not clear to me: How can I get powermanagement > configured so it never dims down my screen brightness (since thats > making the display useless for me) even on low battery? Can I still > adjust what lid-down does in ac, no-ac and low-battery mode (the latter > currently goes into suspend-to-disk as opposed to ram)? Can I still > configure for each profile when it does the suspend? Can I still choose > what "low battery" means? > > I agree though that 2 'low' levels are more or less useless, once the > battery is reaching a very low level I just want the machine to do a > suspend to disk. *facepalm* Let's try to answer this concern once at all: the possibility of editing profiles will NOT be thrown away. To make it easier, here's how the new config UI will work. Take a new KDE installation, open the profile configuration dialog, and forget about the actions at the bottom of the list (new profile, delete profile, etc.). That's pretty much how the UI will look like: you will have 3 profiles, one for each state (AC, Battery, Low Battery) you can configure to your purposes. In addition, you have a separate section where you can override some settings based on which activity you are in. It's exactly like it is now, except you can not MANUALLY change the profile (e.g. by using the applet) > > Andreas -- --- Dario Freddi KDE Developer GPG Key Signature: 511A9A3B 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: Remove waste setTextBackgroundColor for internal KTextEdit in Plasma::TextEdit widget
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102698/#review6989 --- This review has been submitted with commit a50824fcc65a119141db87d0df5f4460f0a59d08 by Alexey Chernov to branch KDE/4.7. - Commit Hook On Sept. 30, 2011, 6:25 a.m., Alexey Chernov wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/102698/ > --- > > (Updated Sept. 30, 2011, 6:25 a.m.) > > > Review request for Plasma. > > > Description > --- > > Removed setTextBackgroundColor() for internal KTextEdit in Plasma::TextEdit > widget. > > It seems to be useless as it's voided by inherited QTextDocument as soon as > all the contents of the TextEdit is removed (even with Backspace key). The > problem is that it also leads to QTBUG-21522 > (http://bugreports.qt.nokia.com/browse/QTBUG-21522) which I mentioned in > kde-devel mailing-list under 'Plasma::TextEdit problem because of > QTextEdit::toHtml() bug' subject. I've sent a patch for that bug, too, but > it's probably not good to have any waste functionality in Plasma itself. > > If there were some serious reasons to add this string, please, note them > here. Otherwise, I think it's worth to be removed. > > > Diffs > - > > plasma/widgets/textedit.cpp 13cc6aa > > Diff: http://git.reviewboard.kde.org/r/102698/diff/diff > > > Testing > --- > > The behavior is the same when used in plasmoids except mentioned Qt bug isn't > reproducible anymore. > > > Thanks, > > Alexey Chernov > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The future of Power Management - together with Activities
On 1 October 2011 21:36, wrote: > > > > Something like having Power mode switch: > > > > [Performance] [Normal] [Battery stretch] > > > > where Normal is current static profile; Performance - temporary disables > > any limitations; Battery stretch - disables everything, that can > > be disabled [Wifi, audio, CPU turbo mode etc] > > This is actually why we thought about pairing profiles and activities. > Although your concern is valid, you are likely to require this kind of > things > when doing a specific activity, hence you won't need the applet :) On the > other hand, inhibition might be useful everywhere. > Not exactly. Those switches was intended to be only temporary changes. Lets say you are on the trip on the train using "Plasma development" activity. Usually, all your development activities are set to average power usage profile, but since the journey is long, and you are not listening to music, nor using wifi [Battery stretch] could give you e.g +25% of battery time. Other situation, you are giving a presentation on how to make a best of QT, that requires compiling using the same using "Plasma development" activity. Performance mode could at the same time disable any screensaver, as well give green light to use all CPU power, ignoring the battery usage. Both are quite unusual but possible situations, but creating new activity and moving all files/settings does not pay off. Also [Performance] and [Battery stretch] power modes could do more by e.g. preventing any daemons (nepomuk, akonadi, owncloud) from staring background works - a common complaint, that KDE semantic services starts at a very bad time and there is no way to prevent them. Cheers, Lukas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The future of Power Management - together with Activities
[Please reply on both lists if you cross-posted, otherwise dicussion will be more fragmented. I just looked up the plasma list out of curiosity, normally I don't follow, so your mail would have been missed.] Dario Freddi wrote: >> I can't comment on activities, never used them, nor feel the need to use >> them. So this sounds more like the power management applet would force >> me to create and use activites. > > Well, if you like to see it that way, yes. Or better, we are trying to > drive forward the concept of "one environment, one setting", where > depending on what you do, the system is going to adapt. I don't like if software forces me to work in a certain way. And with activities I'm not alone. I'm happy without them, even if they are useful for others. Just as I'm mostly happy also without virtual desktops (which are a must for others). People are different, they have different workflows that they don't want to change if there is no *good* reason to do it. > There is still a rationale behind that. If you are in a situation where > you are actually *using* your PC, the only setting available (at the > moment) which is going to affect your battery life is brightness - > everything else is depending on the idle time, and in an emergency > situation one would simply close the lid and suspend straight away. Is it? Certainly disabling desktop effects and 3D acceleration has an impact. And there are other things like when to suspend automatically (if do it at all), when to dim the display, etc. I remember some time ago there was also a possibility to set how fast a CPU would run or throttle down a CPU manually, but I can't see anything like that in the current applet. So I think there are more settings then display brightness (that you usually can control anyway with an Fn shortcut on laptops). If we only talk about the above, and my development example (e.g travelling in an airplane): I know my travel takes 1 hour, my battery can last 2 hours, so I want to use the laptop just as plugged into the wall. I start it, but then it becomes clear there is a delay, so I need to save battery life. Right now I just select a new profile, everything else remains the same on the desktop. Why would I need to switch to a new activity in such case? My work will be the same, just the conditions change. Or while developing I realize I compile more often then needed and this takes more power. So I need to save power in other way, again this would be possible with a simple change in the applet. Please, keep this option. Having a way to control the power magament setting per activity is fine, but leave the possibility to change (and configure) the settings without having to use activities. Andras ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: ScreenSaver and KDE Plasma 4.8?
In data sabato 01 ottobre 2011 19:22:21, Kevin Kofler ha scritto: > Users will not accept your "something better" unless their favorite existing > screensaver runs on it. No amount of communication can change that. (And But one can "feel the pulse" of the users. Blogs, and even more so the KDE Forums could be an interesting area for asking the userbase at large. With my forum admin hat on, I don't mind (in general) disruptive changes as long as they're properly communicated and handled in a way to prevent "rage" (justified or not). After all, in the KDE Forums we don't see anymore people lamenting the lack of icons on desktop by default... -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79 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: The future of Power Management - together with Activities
On Saturday 01 October 2011 19:33:06 Andras Mantia wrote: > On Saturday, October 01, 2011 16:27:48 Dario Freddi wrote: > > Hello all, and sorry for cross-posting. > > > > [...] > > I can't comment on activities, never used them, nor feel the need to use > them. So this sounds more like the power management applet would force > me to create and use activites. Well, if you like to see it that way, yes. Or better, we are trying to drive forward the concept of "one environment, one setting", where depending on what you do, the system is going to adapt. > What I can say that I use the selection combo between the different > power management schemes from time to time, as I can do the same thing > (e.g developing so not anything like now I develop and then switch to > mail reading/watching a movie), but depending on the battery status and > the known time until I can recharge the battery, I can tweak the power > management setting. There is no way any software could guess when will I > be able to recharge my battery. There is still a rationale behind that. If you are in a situation where you are actually *using* your PC, the only setting available (at the moment) which is going to affect your battery life is brightness - everything else is depending on the idle time, and in an emergency situation one would simply close the lid and suspend straight away. Given the power manager is already smart enough to remember your brightness level until you switch state, you are already covered on that part. You might be losing something if you are using the "Run Script" part indeed or if we are going to add something (like auto-switching off peripherals) in the future - for that I have no fix, unless creating a special "Powersave" activity, which is not very different from what you do now, and you also have a shortcut for switching to it, and I think it's an acceptable drawback for the gain we get in return. > > Andras > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel -- --- Dario Freddi KDE Developer GPG Key Signature: 511A9A3B 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: The future of Power Management - together with Activities
On Saturday, October 01, 2011 16:27:48 Dario Freddi wrote: > Hello all, and sorry for cross-posting. > [...] I can't comment on activities, never used them, nor feel the need to use them. So this sounds more like the power management applet would force me to create and use activites. What I can say that I use the selection combo between the different power management schemes from time to time, as I can do the same thing (e.g developing so not anything like now I develop and then switch to mail reading/watching a movie), but depending on the battery status and the known time until I can recharge the battery, I can tweak the power management setting. There is no way any software could guess when will I be able to recharge my battery. Andras ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: ScreenSaver and KDE Plasma 4.8?
Aaron J. Seigo wrote: > unless we give them something better and communicate with understanding. Users will not accept your "something better" unless their favorite existing screensaver runs on it. No amount of communication can change that. (And please don't shoot the messenger! I don't even use a screensaver myself, so I personally couldn't care less about this change.) Kevin Kofler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The future of Power Management - together with Activities
On Saturday 01 October 2011 18:15:53 Lukas wrote: > Hi, > > On 1 October 2011 17:59, wrote: > > Message: 5 > > > > > > At the same time, the combobox for selecting a profile in the battery > > applet > > will be removed. It will, although, be replaced by a toggle button for > > inhibition: by enabling/disabling it, power management features regarding > > screen suspension, notifications and screen power management will be > > suspended. Technically speaking, the battery applet will trigger a full > > inhibition on the power manager while this button is still on. > > Something like having Power mode switch: > > [Performance] [Normal] [Battery stretch] > > where Normal is current static profile; Performance - temporary disables > any limitations; Battery stretch - disables everything, that can > be disabled [Wifi, audio, CPU turbo mode etc] This is actually why we thought about pairing profiles and activities. Although your concern is valid, you are likely to require this kind of things when doing a specific activity, hence you won't need the applet :) On the other hand, inhibition might be useful everywhere. > > > And how do we cope with the users wanting to have very specific behavior > > in certain situations? This is where activities kick in. We will allow > > to configure a "profile" for each activity, if the user wants to, in two > > different ways: action override and profile override. Let me expand. > > Sound awesome :) > > I hope there would be a way to pin profile of other activity? > > Say you have 10 profiles named "Project [project name]". To have same > profile for work activities user could just set "Use same profile as in > 'Project default' ". > > Its different from cloning settings then creating new activity, since any > changes on 'Project default' would be applied on all "Project [project > name]" Good idea. Will try and do that. > > P.s. power profiles can define brightness, so if different activities has > different power profiles with brightness set up, there should be some kind > of scheme of preventing blinking screen when Meta+tab is used to toggle > profiles. Good point as well, thanks. Will take care of it, probably by delaying the switch of 1s. -- --- Dario Freddi KDE Developer GPG Key Signature: 511A9A3B 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: The future of Power Management - together with Activities
Hi, On 1 October 2011 17:59, wrote: > Message: 5 > > > At the same time, the combobox for selecting a profile in the battery > applet > will be removed. It will, although, be replaced by a toggle button for > inhibition: by enabling/disabling it, power management features regarding > screen suspension, notifications and screen power management will be > suspended. Technically speaking, the battery applet will trigger a full > inhibition on the power manager while this button is still on. > Something like having Power mode switch: [Performance] [Normal] [Battery stretch] where Normal is current static profile; Performance - temporary disables any limitations; Battery stretch - disables everything, that can be disabled [Wifi, audio, CPU turbo mode etc] > And how do we cope with the users wanting to have very specific behavior in > certain situations? This is where activities kick in. We will allow to > configure a "profile" for each activity, if the user wants to, in two > different ways: action override and profile override. Let me expand. > Sound awesome :) I hope there would be a way to pin profile of other activity? Say you have 10 profiles named "Project [project name]". To have same profile for work activities user could just set "Use same profile as in 'Project default' ". Its different from cloning settings then creating new activity, since any changes on 'Project default' would be applied on all "Project [project name]" P.s. power profiles can define brightness, so if different activities has different power profiles with brightness set up, there should be some kind of scheme of preventing blinking screen when Meta+tab is used to toggle profiles. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The future of Power Management - together with Activities
On Saturday 01 October 2011, Dario Freddi wrote: > > this i guess would be a kind of "presentation mode"... > > would it still cover enough use cases? > > maybe together with activities could be enough, not 100% sure > > Well, covering all use cases is something I don't feel I can guarantee for > anything :D But we didn't manage to find something this paradigm wouldn't > cover. > and not that now covers everything, so shouldn't particularly be a regression > > yes, i like tying them to activities.. > > basically the profile config ui would stay, but save only > > activity-specific settings? > > Not exactly. You can still configure profiles for battery states (namely: > Performance, Powersave, Aggressive Powersave) as you were doing before, > except now they are tied 1:1 with the battery state. In addition, you can > define activity-specific behavior. I think that's a big +1 from here ;) Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The future of Power Management - together with Activities
On Saturday 01 October 2011 17:01:34 Jeremy Whiting wrote: > Your use of the word "activity" here is referring to plasma > activities? Or Activity is just the name of user-defined power > profiles? Plasma activities -- --- Dario Freddi KDE Developer GPG Key Signature: 511A9A3B 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: The future of Power Management - together with Activities
On Sat, Oct 1, 2011 at 8:59 AM, Dario Freddi wrote: > On Saturday 01 October 2011 16:55:54 Marco Martin wrote: >> On Saturday 01 October 2011, Dario Freddi wrote: >> > Hello all, and sorry for cross-posting. >> > At the same time, the combobox for selecting a profile in the battery >> > applet will be removed. It will, although, be replaced by a toggle button >> > for inhibition: by enabling/disabling it, power management features >> > regarding screen suspension, notifications and screen power management >> > will be suspended. Technically speaking, the battery applet will trigger >> > a full inhibition on the power manager while this button is still on. >> >> this i guess would be a kind of "presentation mode"... >> would it still cover enough use cases? >> maybe together with activities could be enough, not 100% sure > > Well, covering all use cases is something I don't feel I can guarantee for > anything :D But we didn't manage to find something this paradigm wouldn't > cover. > >> >> > Suppose you want to have an activity named "Sleep", in which you watch a >> > movie, and the PC will shutdown after 90 mins of inactivity. In this >> > case, you would just specify to override the "Suspend Session" action. >> > Or, you want to have an activity where you always want a profile which >> > lets you run at full speed. You can define a whole new profile for it. >> > Bottom line: manual profiles become "activity profiles". >> > >> > Hopefully, this solution will please everyone and will make activities >> > even more useful. Do you like it? More suggestions? Speak now or shut up >> > forever! >> >> yes, i like tying them to activities.. >> basically the profile config ui would stay, but save only activity-specific >> settings? > > Not exactly. You can still configure profiles for battery states (namely: > Performance, Powersave, Aggressive Powersave) as you were doing before, except > now they are tied 1:1 with the battery state. In addition, you can define > activity-specific behavior. > Your use of the word "activity" here is referring to plasma activities? Or Activity is just the name of user-defined power profiles? Jeremy >> >> Cheers, >> Marco Martin > > -- > --- > > Dario Freddi > KDE Developer > GPG Key Signature: 511A9A3B > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The future of Power Management - together with Activities
On Saturday 01 October 2011 16:55:54 Marco Martin wrote: > On Saturday 01 October 2011, Dario Freddi wrote: > > Hello all, and sorry for cross-posting. > > At the same time, the combobox for selecting a profile in the battery > > applet will be removed. It will, although, be replaced by a toggle button > > for inhibition: by enabling/disabling it, power management features > > regarding screen suspension, notifications and screen power management > > will be suspended. Technically speaking, the battery applet will trigger > > a full inhibition on the power manager while this button is still on. > > this i guess would be a kind of "presentation mode"... > would it still cover enough use cases? > maybe together with activities could be enough, not 100% sure Well, covering all use cases is something I don't feel I can guarantee for anything :D But we didn't manage to find something this paradigm wouldn't cover. > > > Suppose you want to have an activity named "Sleep", in which you watch a > > movie, and the PC will shutdown after 90 mins of inactivity. In this > > case, you would just specify to override the "Suspend Session" action. > > Or, you want to have an activity where you always want a profile which > > lets you run at full speed. You can define a whole new profile for it. > > Bottom line: manual profiles become "activity profiles". > > > > Hopefully, this solution will please everyone and will make activities > > even more useful. Do you like it? More suggestions? Speak now or shut up > > forever! > > yes, i like tying them to activities.. > basically the profile config ui would stay, but save only activity-specific > settings? Not exactly. You can still configure profiles for battery states (namely: Performance, Powersave, Aggressive Powersave) as you were doing before, except now they are tied 1:1 with the battery state. In addition, you can define activity-specific behavior. > > Cheers, > Marco Martin -- --- Dario Freddi KDE Developer GPG Key Signature: 511A9A3B 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: The future of Power Management - together with Activities
On Saturday 01 October 2011, Dario Freddi wrote: > Hello all, and sorry for cross-posting. > At the same time, the combobox for selecting a profile in the battery > applet will be removed. It will, although, be replaced by a toggle button > for inhibition: by enabling/disabling it, power management features > regarding screen suspension, notifications and screen power management > will be suspended. Technically speaking, the battery applet will trigger a > full inhibition on the power manager while this button is still on. this i guess would be a kind of "presentation mode"... would it still cover enough use cases? maybe together with activities could be enough, not 100% sure > Suppose you want to have an activity named "Sleep", in which you watch a > movie, and the PC will shutdown after 90 mins of inactivity. In this case, > you would just specify to override the "Suspend Session" action. Or, you > want to have an activity where you always want a profile which lets you > run at full speed. You can define a whole new profile for it. Bottom line: > manual profiles become "activity profiles". > > Hopefully, this solution will please everyone and will make activities even > more useful. Do you like it? More suggestions? Speak now or shut up > forever! yes, i like tying them to activities.. basically the profile config ui would stay, but save only activity-specific settings? Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The future of Power Management - together with Activities
On Saturday 01 October 2011 16:39:38 Alexander Neundorf wrote: > Not sure about coupling them with activities... > > There are actually two other issues I have right now with the power > management: Well, those are actually bugs, hence slightly OT. Anyway... > > 1) it has per-user settings. > This becomes really strange when multiple users are logged in into one > notebook. This should be a systemwide setting. I don't agree on this one: different users might have different policies. Also, if your PC has ConsoleKit installed on it (which is likely), the power manager acts only on the active session. > > 2) I think I still have the problem that when the session is locked and > the screensaver is active, power management doesn't work, i.e. the > notebook doesn't go to sleep when I close the lid. I suspect this is also > because at that moment no user is active so no user settings are applied. Exactly. This is something which is partly solved, but I'll look at after the new screen locker will be into place. -- --- Dario Freddi KDE Developer GPG Key Signature: 511A9A3B 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: The future of Power Management - together with Activities
On Saturday 01 October 2011, Dario Freddi wrote: > Hello all, and sorry for cross-posting. > > Me and Bjorn have been discussing extensively about how to improve the > current situation with Power Management in KDE. We focused on simplicity, > still without losing power-user features. And we have a plan I'd like to > share and get some feedback on. > > The first, important part: we plan to remove the "Warning" step and the > possibility of creating profiles manually. The reason behind this choice > will be clearer later. So we will have just 3 static profiles: one for AC > power, one for the PC running on battery, one for the PC running on low > battery. > > At the same time, the combobox for selecting a profile in the battery > applet will be removed. It will, although, be replaced by a toggle button > for inhibition: by enabling/disabling it, power management features > regarding screen suspension, notifications and screen power management > will be suspended. Technically speaking, the battery applet will trigger a > full inhibition on the power manager while this button is still on. > > And how do we cope with the users wanting to have very specific behavior in > certain situations? This is where activities kick in. We will allow to > configure a "profile" for each activity, if the user wants to, in two > different ways: action override and profile override. Let me expand. > > Suppose you want to have an activity named "Sleep", in which you watch a > movie, and the PC will shutdown after 90 mins of inactivity. In this case, > you would just specify to override the "Suspend Session" action. Or, you > want to have an activity where you always want a profile which lets you > run at full speed. You can define a whole new profile for it. Bottom line: > manual profiles become "activity profiles". > > Hopefully, this solution will please everyone and will make activities even > more useful. Do you like it? More suggestions? Speak now or shut up > forever! Not sure about coupling them with activities... There are actually two other issues I have right now with the power management: 1) it has per-user settings. This becomes really strange when multiple users are logged in into one notebook. This should be a systemwide setting. 2) I think I still have the problem that when the session is locked and the screensaver is active, power management doesn't work, i.e. the notebook doesn't go to sleep when I close the lid. I suspect this is also because at that moment no user is active so no user settings are applied. Alex ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
The future of Power Management - together with Activities
Hello all, and sorry for cross-posting. Me and Bjorn have been discussing extensively about how to improve the current situation with Power Management in KDE. We focused on simplicity, still without losing power-user features. And we have a plan I'd like to share and get some feedback on. The first, important part: we plan to remove the "Warning" step and the possibility of creating profiles manually. The reason behind this choice will be clearer later. So we will have just 3 static profiles: one for AC power, one for the PC running on battery, one for the PC running on low battery. At the same time, the combobox for selecting a profile in the battery applet will be removed. It will, although, be replaced by a toggle button for inhibition: by enabling/disabling it, power management features regarding screen suspension, notifications and screen power management will be suspended. Technically speaking, the battery applet will trigger a full inhibition on the power manager while this button is still on. And how do we cope with the users wanting to have very specific behavior in certain situations? This is where activities kick in. We will allow to configure a "profile" for each activity, if the user wants to, in two different ways: action override and profile override. Let me expand. Suppose you want to have an activity named "Sleep", in which you watch a movie, and the PC will shutdown after 90 mins of inactivity. In this case, you would just specify to override the "Suspend Session" action. Or, you want to have an activity where you always want a profile which lets you run at full speed. You can define a whole new profile for it. Bottom line: manual profiles become "activity profiles". Hopefully, this solution will please everyone and will make activities even more useful. Do you like it? More suggestions? Speak now or shut up forever! -- --- Dario Freddi KDE Developer GPG Key Signature: 511A9A3B 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: ScreenSaver and KDE Plasma 4.8?
On Samstag 01 Oktober 2011 14:10:39 Marco Martin wrote: > for saving from damage, there is a thing called "power saving" :p Doesn't help the people who want a huge clock as screensaver without damaging their displays. It has to move. A Plasma containment whose widgets can float and bounce from another (like soap bubbles) should be enough. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: ScreenSaver and KDE Plasma 4.8?
On Samstag 01 Oktober 2011 12:36:12 Aaron J. Seigo wrote: > we should also stress that if things like OpenGL screensavers are important > enough to people, that support for "things to draw moving things on screen > when locked" can be created anew. We already have KWin effects – even gimmicky ones like Snow. Apart from some (I imagine relatively simple to implement) call “stop effect XY on any input” isn't that enough? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: ScreenSaver and KDE Plasma 4.8?
On Saturday 01 October 2011, Markus Slopianka wrote: > On Samstag 01 Oktober 2011 10:52:04 Marco Martin wrote: > > that's what the support of plamoids on screensaver is for ;) > > I already understood that but as a screensaver (you know: to actually save > screens from damage, incl. LCDs) a few additional features are required. > At the very least, plasmoids would need to move. for saving from damage, there is a thing called "power saving" :p -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: ScreenSaver and KDE Plasma 4.8?
On Samstag 01 Oktober 2011 10:52:04 Marco Martin wrote: > that's what the support of plamoids on screensaver is for ;) I already understood that but as a screensaver (you know: to actually save screens from damage, incl. LCDs) a few additional features are required. At the very least, plasmoids would need to move. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: ScreenSaver and KDE Plasma 4.8?
On Saturday, October 1, 2011 11:46:43 Martin Gräßlin wrote: > > rather don't do this "if only one user is configured" as > > a) this is rather never the case (does kdm know that "sauerbraten" and > > "mpd" are no regular users? what about "nobody", "fetchmail" yes, kdm does. this is how it knows which users to show at the login screen, and the accounts you mention do not show up in kdm. > > b) breaks other session types (openbox, e17) - of course a kde user > > would never do, but kde should prevent it neither ;-) ont at all. kdm (or whatever manages this in the future) could simply look at what the default shell is. the heuristic is then simple: if Plasma Desktop and exists Default User, automagic log in to locked screen. could be switched off quite easily; this is really most about defaults and some very small changes to kdm. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks 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: ScreenSaver and KDE Plasma 4.8?
On Thursday, September 29, 2011 23:49:50 Kevin Kofler wrote: > Martin Gräßlin wrote: > > * drop screensaver support altogether, probably would create some troubles > > as evil KDE removed screensavers > > * add Plasma widget support to new screen locker implementation but drop > > screensaver support (same problems as first option) > > I don't think these are acceptable. Our users will complain loudly if their > screensavers stop working. unless we give them something better and communicate with understanding. as someone else noted, understanding how and why people use this feature will be helpful. communicating clearly the path forward with wayland, lock screens that meet all current use cases and the security problems with the current x screensavers will be vital. i really like martin's 4.8 -> 4.9 plan as it will give us a natural opportunity for this communication. we also need to show what is possible with the QML solution we are offering, which is pretty flexible already. we should also stress that if things like OpenGL screensavers are important enough to people, that support for "things to draw moving things on screen when locked" can be created anew. it's not that screensavers are somehow inherently evil, just that the 20 year old implementation (as of 2012; first release was in 1992) of them is no longer fit for today's systems, and we currently do not have the manpower to reimpliment that feature set with our current resources. i think it would make a fine user-supported add-on. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks 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: ScreenSaver and KDE Plasma 4.8?
- Ursprüngliche Mitteilung - > Am Thu, 29 Sep 2011 22:14:59 +0200 > schrieb Martin Gräßlin : > > > But when compositing is turned off, you currently get the plain old > > implementation including screen savers. And I don't want to change > > that code. > Seconding Marco: "Why?" it's such a hack around X that I fear it falls apart as soon as I touch it ;-) No really I prefer not to spend too much time on legacy code. > > > So there are some solutions: > > * drop screensaver support altogether, probably would create some > > troubles as evil KDE removed screensavers > +1 > > > A possible solution for the user issue could be to clearly advertise > > that security reasons are responsible for removing screensaver > > support. > gg:greenwashing > Just stress that aspect and best back it with some facts about the last > available CRTs and "burn-in-with-lcd" myths. > Otherwise you'll have to explain > a) "why is compositing such shit?" > b) "but it works with windows" > c) "can't you implement screensavers as kwin effects then?" (yeah, but > i won't! why? i think it's retarded. you suck! KDE sucks!! FOSS > sucks i'm gonna use window" blabbbabb) > > > Also an improved login process I have in my mind: with only > > one user configured > "kcmshell4 kdm", convenience, enable auto-login, lock session that's what I had in my mind :-) > > rather don't do this "if only one user is configured" as > a) this is rather never the case (does kdm know that "sauerbraten" and > "mpd" are no regular users? what about "nobody", "fetchmail" > b) breaks other session types (openbox, e17) - of course a kde user > would never do, but kde should prevent it neither ;-) It would require support from distributions, properly even only possible during insallation. Cheers Martin > > Cheers, > Thomas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: ScreenSaver and KDE Plasma 4.8?
On Saturday 01 October 2011, Markus Slopianka wrote: > Is anybody aware of empiric studies for what (if at all) people use > screensavers these days? > Personally I'd expect clock, news headlines, and photo slideshows to be the > top answers. QML replacements should be available for the top uses once > the xscreensaver code is dropped. (IMHO at least.) that's what the support of plamoids on screensaver is for ;) (that as aaron noted implementing it in the lock effect will be dramatically easy) -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
