On Monday 03 October 2011 06:38:29 Scott Kitterman wrote: > On Sunday, October 02, 2011 06:44:41 PM Dario Freddi wrote: > > I would like to draw your attention to the address of this list. It > > has a nice -devel prefix. I don´t take part in discussions where I am > > not knowledgeable about the topic. So far the answers I got are among > > this category. > > > > - I have never used those features,but I am voicing random crap about > > > > changing them > > > > - I have a strong opinion I will keep stating, and refuse to answer > > > > your replies about my concerns or reading what you wrote previously > > and keep going on my line. > > > > Seriously, has anybody answered my statements about brightness > > vs.everything else and creating profiles vs. creating activities? > > I certainly think I have. > > I've said I think the concept of activities (what you are doing) is > generally orthogonal to when I want the system to do things different for > power management (where I am), so trying to connect them will be > confusing. I don't feel like you've addressed that.
It might indeed have been unclear, so I'll try to dedicate this mail to this very topic. Let me start by saying that of course you are not wrong by saying the concepts are orthogonal, but that would be true if activities were the only way to provide such a feature. Let's now analyze the job of a _session_ power manager (I want to put the accent on session as it's the bit which makes the difference). Some people (like me) usually refer to it as a policy daemon: it just enforces a particular policy on some behaviors of the system. This policies are usually referring just to how the PC handles idle timeouts, as you can see from the configuration UI itself. Before going on, I will also restate something I said in a previous mail but in a different context: when dealing with such parts of the system, we usually want to sacrifice corner cases if they might lead to a misuse. Now, one of the strongest arguments I put in this thread is the fact that the only setting which is going to affect your PC is battery. Consider every possible use case for changing a profile should be changed manually. In this cases, we are likely just handling the idle time. Brightness is already smart enough to be transient and configurable regardless of each profile, even though you usually don't notice (which is good). - I am working and I need full power: there are no settings which can help you, and the fact that you are working are preventing any of the idle time- based policies - I am working and I strive to save as much power: again, there's not much use in a different profile: you are working, so your idle time will never be enough. - I don't need some peripherals: this concept is orthogonal to power management just as activities are, if you think about it. First of all, if I had 3 peripherals which can be turned off, I would need 3!=6 separate profiles to cover all needs: I might want in fact to save as much power as possible, but I might need to have 1 or 2 of those active. Besides, this approach simply doesn't scale: the profile is gonna be fitting *only* your hardware needs. You are not guaranteed you want the same policies to be applied when one of your peripherals is turned off: maybe you just want to turn bluetooth off because you feel like it but without going crazy on the powersave timeouts. Instead, the right approach with these things is to disable them from their own applet. If you think how a user approaches this, it does it in exactly this way. They KNOW they have to go to the network manager to turn off the wifi card or to the bluetooth applet to disable bluetooth in order to do that (which I expressed in an unfortunate way in my previous comment about "geekish ways of acting"). So, even though such a thing might be present in a policy daemon, it's a use case so small we probably don't want to support, and which might lead to misuse. I would like to start from point 3 to advocate the use of activities instead. First of all, the configuration for activities will not look exactly like the "profiles" one. It will, of course, give you the option to "create" a new profile for people who really want that, but mainly it will provide a "simplified" configuration which is able to override some behaviors: for example, "never suspend the PC", "always shutdown after an hour", etc... What does this mean? For your current activity, you will always have the same needs: to take the most simple case, when watching a movie you will never want your screen to turn off, even if you're on crazy power saving mode (even though brightness might be useful). This means your activity will just override the settings YOU care about, and will leave the rest to the sane defaults, which are ALWAYS STRIVING TO SAVE AS MUCH POWER AS POSSIBLE, and I all caps'ed that because it's the whole point of the discussion. But - and here it's important to notice - there are things which are never related to activities. Peripherals is the perfect example. But if you switch off a peripheral the proper way instead of switching to a different profile, you will get an even better effect. You will save power from that, still by using the right defaults for your state, and eventually some overrides for what you are currently doing. I guess you can see why this approach is more convenient. Of course, in the future we might think about adding a "switch off wifi" to the activity config, as when doing some things you don't need some peripherals - but it's not exactly relevant in analyzing your issue and your concern. Maybe now it's also clearer why the main job of a policy daemon is to prevent power management. Our defaults are always striving to save each bit of energy if you are away from your PC, and you have to remember that! Our first aim is to save power. But at the same time, saving power comes at a price, and we're always trying to be smarter and smarter. I really believe with this approach, which I reckon might not be immediate to understand as I explained it, the means of control over your power manager will be more instead of less, and most of all better. Hope this addresses your concern. > > I apologize for being harsh earlier. Cleary you didn't feel like what you > were saying was being heard. I didn't either. Np, arguing is natural, but intelligent people always manage to solve that :) > > Scott K -- ------------------- 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
