Re: Review Request 123169: Show percentage value beside brightness level slider
On March 29, 2015, 6:34 p.m., Kai Uwe Broulik wrote: Thank you for this patch! However, we chose to remove the percentage from the brightness sliders in the battery monitor since you basically change the brightness to your liking and not to some odd percentage, so adding them back in the PowerDevil settings doesn't make sense. Siddhartha Sahu wrote: Hi Kai, Yes for the battery monitor it is not really required because we get immediate feedback. In the KCM, the sliders are for different profiles which come into play at different times. I do not like the brightness change that happens when I remove my AC adaptor for example, so I keep the brightness levels the same in all the profiles. Setting it the same is a tad tedious currently because I need to swtich tabs multiple times to check if both are in the same position. Well, I guess mine is a very special case, and would understand if this patch does not really make sense in the main repo. I can keep using it as a special patch on my end :) Kai Uwe Broulik wrote: What speaks against just unchecking the brightness action? Then it won't change it when you plug in or out the AC. I hate when it messes with my brightness, so I just turned everything off and only ever manually change it :) Siddhartha Sahu wrote: Ah. Why did I not think of that. Obvious in hindsight :D Discarding the RR then. Thanks! Teemu Rytilahti wrote: This is probably not the proper forum to ask, but the annoying problem of jumpy brightness would in my opinion better be solved by just saving the brightness to the active profile when the brightness gets changed. That way it would at least be consistent even though powerdevil decides that it's time to change the profile.. Unfortunately it's a design decision to keep it the way it is, iirc? Thomas Lübking wrote: How's that effectively different from preventing powerdevil to adjust the brightness itfp? Ah, sorry, I was thinking about something else there, namely making it easier to adjust the profile brightnesses to be used by the active profile. - Teemu --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123169/#review78180 --- On March 29, 2015, 6:59 p.m., Siddhartha Sahu wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123169/ --- (Updated March 29, 2015, 6:59 p.m.) Review request for kde-workspace. Repository: powerdevil Description --- I prefer to keep the same brightness level for all profiles. But its a bit difficult to set the same value in all tabs using just the slider. This patch adds a percentage value next to the slider. Screenshot included. Diffs - daemon/actions/bundled/brightnesscontrolconfig.h 7ba29a7 daemon/actions/bundled/brightnesscontrolconfig.cpp 3b5aaad Diff: https://git.reviewboard.kde.org/r/123169/diff/ Testing --- Compiles. KCM displays the percentage corresponding to slider value in all tabs. File Attachments Slider with percentage https://git.reviewboard.kde.org/media/uploaded/files/2015/03/29/359f2e65-c52c-4e4e-9c8a-c75c3a9a8576__kcm.png Thanks, Siddhartha Sahu
Re: Review Request 123169: Show percentage value beside brightness level slider
On March 29, 2015, 6:34 p.m., Kai Uwe Broulik wrote: Thank you for this patch! However, we chose to remove the percentage from the brightness sliders in the battery monitor since you basically change the brightness to your liking and not to some odd percentage, so adding them back in the PowerDevil settings doesn't make sense. Siddhartha Sahu wrote: Hi Kai, Yes for the battery monitor it is not really required because we get immediate feedback. In the KCM, the sliders are for different profiles which come into play at different times. I do not like the brightness change that happens when I remove my AC adaptor for example, so I keep the brightness levels the same in all the profiles. Setting it the same is a tad tedious currently because I need to swtich tabs multiple times to check if both are in the same position. Well, I guess mine is a very special case, and would understand if this patch does not really make sense in the main repo. I can keep using it as a special patch on my end :) Kai Uwe Broulik wrote: What speaks against just unchecking the brightness action? Then it won't change it when you plug in or out the AC. I hate when it messes with my brightness, so I just turned everything off and only ever manually change it :) Siddhartha Sahu wrote: Ah. Why did I not think of that. Obvious in hindsight :D Discarding the RR then. Thanks! This is probably not the proper forum to ask, but the annoying problem of jumpy brightness would in my opinion better be solved by just saving the brightness to the active profile when the brightness gets changed. That way it would at least be consistent even though powerdevil decides that it's time to change the profile.. Unfortunately it's a design decision to keep it the way it is, iirc? - Teemu --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123169/#review78180 --- On March 29, 2015, 6:59 p.m., Siddhartha Sahu wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123169/ --- (Updated March 29, 2015, 6:59 p.m.) Review request for kde-workspace. Repository: powerdevil Description --- I prefer to keep the same brightness level for all profiles. But its a bit difficult to set the same value in all tabs using just the slider. This patch adds a percentage value next to the slider. Screenshot included. Diffs - daemon/actions/bundled/brightnesscontrolconfig.h 7ba29a7 daemon/actions/bundled/brightnesscontrolconfig.cpp 3b5aaad Diff: https://git.reviewboard.kde.org/r/123169/diff/ Testing --- Compiles. KCM displays the percentage corresponding to slider value in all tabs. File Attachments Slider with percentage https://git.reviewboard.kde.org/media/uploaded/files/2015/03/29/359f2e65-c52c-4e4e-9c8a-c75c3a9a8576__kcm.png Thanks, Siddhartha Sahu
Re: Re: Login for bug reporting
Martin Gräßlin wrote: That depends on how the easier works. Email address only is for me a big no- no as it means that the user cannot add attachments, which is quite important in the case of a crash trace. Attachments should be possible with just an e-mail address / automatic account creation, I think. if the backtraces go to a special system where I don't see the dups, I'm all fine. If they go to bugzilla I want less and I mean it. The number of duplicates is a real problem and costs us lot's of time and work. I don't want to see anything done to make it easier. And no, we cannot expect users to recognize a duplicate crash, That's too difficult, we can also not expect users from recognizing whether a backtrace is useful. True, it's up to the system to handle dups and invalid backtraces, imo. -- Best Regards, Teemu Rytilahti
Re: Login for bug reporting
Martin Sandsmark wrote: On Thu, Feb 07, 2013 at 01:58:14AM +0100, Teemu Rytilahti wrote: What kind of reports are those useless ones? Dupes? Downstream bugs? Missing information? In my opinion reporting bugs to b.k.o is not that easy (or I've become lazy) as it should be and that's why I'm wondering.. All of the above, as well as obvious PEBKACs and support requests. Dupes for crashes should be an easy one. Downstream bugs not so. Missing information, can we get some of that information automatically from the user's system, like e.g. Ubuntu and Mozilla are doing? PEBKACs and support requests for crashes? Though for regular bug reporting I would like to see something similar to what Mozilla does; forward the user clearly needing support to forums and/or userbase, from the report a bug or b.k.o's bug input page.. -- Best Regards, Teemu Rytilahti
Re: Login for bug reporting
Hi everyone, Frank Reininghaus wrote: considering that we get lots of duplicates for any reproducible bug, my impression is actually not that there are to many obstacles in the bug reporting process. Providing any kind of contact me via email/Facebook channel will only make it worse. I'm already spending a lot of time marking reports as duplicate/invalid or telling people that reporting bugs for KDE 4.8 or earlier is not quite as useful as they think. Please do not make it worse by lowering the bug reporting barriers. The duplicate problem is really an issue I'm sure, but the partial solution might be to use a separate crash-tracker like Nicolás mentioned. Basically the crash-tracker would collect the crash information, from which the bug reports can be made if/when needed. Actually this might even make the situation better for the triaging (aggregation, dupfinding, keeping b.k.o clean..), but can't say for sure of course. I'm not (yet) sure how the process works for Mozilla folks, but all the crashes are reported to a centralized place and aggregated afaik, all done without logging. The bug entries in their Bugzilla are then linked (and vice-versa?) to the crash reports, see https://crash- stats.mozilla.com/products/Firefox . Btw, what kind of reports are they mostly you're marking as dupes/invalids? Not crashes I assume, as DrKonqi should do dupe-checking before letting one to submit reports.. -- Best Regards, Teemu Rytilahti
Re: Login for bug reporting
Hi, Rolf Eike Beer wrote: I want to hijack this thread, as it is similar to what I find annoying (but for a totally different reason). I have an account, but sometimes I hack around at other peoples machines. I usually don't have my credential there and I don't even want to put them on this machines. But when I see a crash I would like to have Dr. Konqi to be able to tell me if this is a dupe or not. If it is I could just dump the trace and go on, if it is not I could still save it and report it back at home. Currently I need to log in before it is able to find dupes, which is IMHO not necessary as the information in public. Agreed. And in the same breath it would be nice to relay information about already fixed bugs ala This bug has been fixed in version x or You can use this thing as a workaround. I'm sure there are plenty of cases where a work- around information would be really useful also in cases when the bug is not easily fixable (see AkregatorMetakit crashes, some KWin crashes probably too?). -- Best Regards, Teemu Rytilahti
Re: Login for bug reporting
Hello, Myriam Schweingruber wrote: I fully agree with Frank here, we already get way enough useless reports, please don't lower the barrier even more. IMHO it is already very easy to report a bug in BKO, much easier actually than in other bug trackers out there, and, unless you find a miracle solution to increase the number of triagers at least 10x the current number, lowering the barrier would also mean more bogus and spam. Please don't make our work harder than it already is. What kind of reports are those useless ones? Dupes? Downstream bugs? Missing information? In my opinion reporting bugs to b.k.o is not that easy (or I've become lazy) as it should be and that's why I'm wondering.. Bogus spam can probably be handled more or less automatically, when we know what we want and what's are the problems currently. -- Best Regards, Teemu Rytilahti
Re: Login for bug reporting
Hi, Martin Graesslin wrote: +1 from me. I don't want reports from users not willing to create an account So easier account creation is also a big no-no? For crashes or for all bugs? Mozilla allows one to supply an e-mail address if the user is willing for that, but still allows sending the traces for aggregation. That doesn't apply for regular bugs though... -- Best Regards, Teemu Rytilahti
Re: Login for bug reporting
Hi again, Frank Reininghaus wrote: considering that we get lots of duplicates for any reproducible bug, my impression is actually not that there are to many obstacles in the bug reporting process. Providing any kind of contact me via email/Facebook channel will only make it worse. I'm already spending a lot of time marking reports as duplicate/invalid or telling people that reporting bugs for KDE 4.8 or earlier is not quite as useful as they think. Please do not make it worse by lowering the bug reporting barriers. Just wanted to add also, that in case the version stuff is a problem, entering the bugs can be limited of course. I think the big thing with 4.8 crashes might be that they're already fixed and there's a solution available (upgrade), in which case that information could be delivered directly to the user (though when collecting all the crashes to a separate crash reporting system, it'll give nice stats how common the crash is) without even adding that information to the bug-tracker. -- Best Regards, Teemu Rytilahti
Re: DrKonqi improvement idea
Niko Sams wrote: Interesting. But no system provides a solution I think. Socorro looks very powerful - but they need to process much more crashes. Actually at least Microsoft does, not sure about the others. Not sure how much is it used though, but the system has a capability to give an url where to get more information and instructions, or even provide a link to a new binary where the problem is fixed. - If there would be a separate crash-site, could it be worth to allow crash reports without login? Maybe. But I would say we need the email address of the user to contact him back. Yup, depends really on how much can be mined if there'd be a huge load of backtraces. Nevertheless, from user point of view asking an email address wouldn't be as bad as having to register to a separate site before getting/submitting the information. - Data sanitation? Ubuntu doesn't reveal the crash reports per default as they might contain something which shouldn't be public. Right. But that sounds like manual work. But currently DrKonqi also just posts the backtrace. True, and this really depends what kind of information is being gathered. One thing interesting which is a bit related is that one possibility would be to gather other information from the system (Perhaps even per app-basis? Automatically getting information about hardware drivers for kwin bugs, as an example). Same applied to other apps might cause some need to sanitize and/or let users to choose what to send. -- Best Regards, Teemu Rytilahti
Re: DrKonqi improvement idea
. Somehow a crash is being confirmed and moved to b.k.o. 7. Live happily ever after. That's my 0.02e for the time being, I think. Sorry for the lengthy mail, but hope there's some food for thought in there. [1] https://blog.mozilla.com/webdev/2010/05/19/socorro- mozilla-crash- reports/ [2] https://crash-stats.mozilla.com/products/Firefox [3] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.148.716rep=rep1type=pdf [4] http://www.piware.de/2011/11/apport-1-90-client-side- duplicate-checking/ [5] https://launchpad.net/bugzilla-traceparser [6] https://git.reviewboard.kde.org/r/102921/ -- Best Regards, Teemu Rytilahti
Re: DrKonqi improvement idea
available for all bugs... I don't get how this is valuable feedback. If I didn't fix a bug of course it will be reproducible in later versions?! Well, from what I've seen in bko people do ask whether the bug is still reproducable, no? I see no reason why this information should pollute the comments section, which should be in my opinion used for discussing the specifics of the bug. - Is there a need to keep duplicate crashes in the database, maybe for false positives? hu? I don't get this one. if it's a duplicate then by definition one doesn't need its information because it's already known?! False positives, if that can happen. Also, this kind of information could be used as a base to see from what kind of things bugs are triggered mostly? But yeah, just thinking... The workflow could be something like this: 1. User encounters a crash and is asked whether to send a report. 2. If yes, a backtrace is being send to the server. 3. If there's a complete match, just inform the user about it and give a link to a bug report / perhaps allow add a new comment to report? only if: bug is not fixed or current version is *higher* than the assumed fixed-in version. Yes. 8. developer fixes bug, associates a solution to the crash, user that reported the crash gets an email notification. this is pretty crucial and the whole point of this proposal... Indeed. Sounds good to me. -- Best Regards, Teemu Rytilahti
