Re: DrKonqi improvement idea
Niko Sams wrote: Hi, Hello, more discussion about how to handle bugs are welcome, I hope. Wasn't able to get in to the earlier thread, so I thought I should post something here. In short: DrKonqi shouldn't create bugs directly but talk to a layer between. This really depends on how it'd be used, but perhaps yeah, this might be a good idea indeed. This is something I encountered while working on a course paper earlier this semester. Similar systems are up there for Mozilla (Socorro[1], shown in here [2], Microsoft [3] and Ubuntu too. I bet that LibreOffice might have something similar too, but haven't looked into that. One thing which makes all of this easier for them though is that they're providing the binaries directly, which basically means that they can do all kinds of niceties out there too. See [4] for an example from Ubuntu-land. This doesn't though mean that we couldn't do similar in KDE too, and it probably would be a good idea. crashes.kde.org is a new web application - a bit similar to bugzilla: - lists all reported crashes with intelligent filtering duplicates I think DrKonqi already can get information whether there's duplicates already with the same backtrace, or at least that information is available for DrKonqi-reported bugs. One thing to consider there would be whether Traceparser[5] (used in Gnome's bugzilla, too) could be used there if needed to get numerical scores for backtraces. - developers can set duplicates Not sure whether this would work, more manual work all around while the triagers are already overloaded afaik. As much as possible should be done automatically. Though I think the duplicate detector in DrKonqi works quite well nowadays and doesn't allow even submit duplicate crashes. - developers can link a crash to a bug (or create automatically a bug for a crash) This is how it works for Mozilla at least if I haven't misunderstand their processes. A good idea. This can be used later on to redirect the user to the bug like you mention later on. - developers can enter a solution (that will be presented to the user that hits this crash) [snip] - comments can be added by users and developers (to ask how to reproduce etc) How about just having the crashes linked to b.k.o entry? So that the crash database would just for crashes, no comments etc. - user posts the crash, crashes.kde.org doesn't find a duplicate. User gets the possibility to subscribe to updates for this crash to get an email when a solution for his crash was entered by the developers I don't like the idea of having a separate place for comments and/or solutions, but that's just me. In my opinion the commenting could happen in a valid b.k.o entry as needed. Advantages over current solution: - bugs.kde.org isn't filled with duplicates Not sure if this is an issue anymore regarding to crashes. Couldn't find the blog entry related to this quickly, but here's a reviewboard entry: [6] . Anyway, the idea is good nevertheless. - sending a crash would not only help developers fixing that bug but also help the user by showing a solution for his issue. This would be a great plus indeed, though would need adaptation on processes depending on how specific solutions should be shown to the user. If fixed-in tags or similar are set to bugs when they're fixed, that information could be easily given to user in a this bug is fixed in version x sense. What software could crashes.kde.org run? I'm not sure, maybe a bugzilla installation or something custom written. Or some other bugtracking software. So, what do you think? Some things to consider: - If there would be a separate crash-site, could it be worth to allow crash reports without login? - Data sanitation? Ubuntu doesn't reveal the crash reports per default as they might contain something which shouldn't be public. - It might be possible to use a separate Bugzilla instance just for this, but I'm not sure how well migrating bugs between instances do work or whether that's worth it. - When getting duplicate backtraces from users the bug entry could be updated automatically with the version the crash happened, this would in my opinion be a plus in a sense that can reproduce in version x entries wouldn't flood the comment section. Anyway, this is something which could be generally available for all bugs... - Is there a need to keep duplicate crashes in the database, maybe for false positives? 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? 4. If no complete matches available, ask user for more information what happened, just like Konqi does already. 5. Make an entry to the crash database. 6.
Re: DrKonqi improvement idea
On Monday 12 March 2012 02:14:00 Teemu Rytilahti wrote: Niko Sams wrote: Hi, Hello, more discussion about how to handle bugs are welcome, I hope. Wasn't able to get in to the earlier thread, so I thought I should post something here. In short: DrKonqi shouldn't create bugs directly but talk to a layer between. This really depends on how it'd be used, but perhaps yeah, this might be a good idea indeed. This is something I encountered while working on a course paper earlier this semester. Similar systems are up there for Mozilla (Socorro[1], shown in here [2], Microsoft [3] and Ubuntu too. I bet that LibreOffice might have something similar too, but haven't looked into that. One thing which makes all of this easier for them though is that they're providing the binaries directly, which basically means that they can do all kinds of niceties out there too. See [4] for an example from Ubuntu-land. This doesn't though mean that we couldn't do similar in KDE too, and it probably would be a good idea. While nice this is not required for Niko's proposal. Either the backtrace is automatically associated with a solution, or a developer later on associates it with a solution or a bug report. In the former case, the user gets direct feedback on what's going on. In the latter, he will at least get a concise email - at least that's what I have in mind (and I think Niko as well). The big difference to our current solution is just that users get far less emails, like bug XYZ marked as duplicate. Or mails for developer discussions in bug reports, something that most users won't understand anyways. crashes.kde.org is a new web application - a bit similar to bugzilla: - lists all reported crashes with intelligent filtering duplicates I think DrKonqi already can get information whether there's duplicates already with the same backtrace, or at least that information is available for DrKonqi-reported bugs. One thing to consider there would be whether Traceparser[5] (used in Gnome's bugzilla, too) could be used there if needed to get numerical scores for backtraces. - developers can set duplicates Not sure whether this would work, more manual work all around while the triagers are already overloaded afaik. As much as possible should be done automatically. Though I think the duplicate detector in DrKonqi works quite well nowadays and doesn't allow even submit duplicate crashes. Hum how is this more work? Actually I cannot see how this can create more work, if at all only the same amount. On the contrary I think Niko's proposal can reduce the workload! The reason is that users should then - in theory - get a concise, short and readable instruction that should explain them how to fix their crash. Update to version XYZ for example. Even in KDevelop, an app where our userbase should be somewhat proficient with the whole development process, we get tons of emails because people add their +1 crashed for me as well backtraces to some hideously old bug report. And why? Because they don't read the bug reports. Somewhere in the comments there might be a fixed by commit xyz message, but they simply don't care. If now they would see a simple this is fixed by version XYZ - please update, then it would help me personally quite much already. Of course we can still improve the backtrace matching eventually, but this is unrelated to the proposal at hand here I think. - developers can link a crash to a bug (or create automatically a bug for a crash) This is how it works for Mozilla at least if I haven't misunderstand their processes. A good idea. This can be used later on to redirect the user to the bug like you mention later on. - developers can enter a solution (that will be presented to the user that hits this crash) [snip] - comments can be added by users and developers (to ask how to reproduce etc) How about just having the crashes linked to b.k.o entry? So that the crash database would just for crashes, no comments etc. +1 either the crash is new - new entry, or the crash is not yet fixed - comment on b.k.o. - user posts the crash, crashes.kde.org doesn't find a duplicate. User gets the possibility to subscribe to updates for this crash to get an email when a solution for his crash was entered by the developers I don't like the idea of having a separate place for comments and/or solutions, but that's just me. In my opinion the commenting could happen in a valid b.k.o entry as needed. yes, see above. solutions should be separated though - otherwise people won't find it. that's the crucial point here I think. Advantages over current solution: - bugs.kde.org isn't filled with duplicates Not sure if this is an issue anymore regarding to crashes. Couldn't find the blog entry related to this quickly, but here's a reviewboard entry: [6] . Anyway,
Re: DrKonqi improvement idea
On Sunday 11 March 2012 11.26.53 Niko Sams wrote: I'd like to talk about an idea on how DrKonqi [] What software could crashes.kde.org run? I'm not sure, maybe abugzilla installation or somethingcustom written. Or some other bugtracking software. I'd say this is a great idea, mostly because it means a lot more can be automated on lots of ends. Naturally, the actual automation means research and development, which means manpower. I didn't get from your email if you wanted to volunteer for some of this work :) Personally I'd go for a solution that also tries to register the last 20 keystrokes and 20 mouse clicks (qt global event listener) and if and when a crash occurs that info can be send with the backtrace. So even if there are no debug packages installed we get some info to do data-mining on. I'd also make your webpage (or site) be mostly dumb in the handling of the data its being sent and then have a continues job on the machine to actually process and handle these crash reports. So if we get loads of requests in, we just store the data to be processed when there is CPU available. The reason is that I think we get much more useful information out of this if we allow it to take more time than a webrequest would allow. And also this will make the site much more responsive and painless. It just scales better ;) Either case, I'd think you want something custom written. Its not too much work to do the basics and maybe we can steal some code that compares backtraces and steal some ideas or code for on-disk data-store of those backtraces. Niko, I'm wondering if you can help out with realization of your ideas, and if you have php or perl skills for instance. I might find some time on my hands, and it sounds like a fun (and needed) project so I could help out. Cheers -- Thomas Zander
Re: DrKonqi improvement idea
Milian Wolff wrote: Hi again, While nice this is not required for Niko's proposal. Either the backtrace is automatically associated with a solution, or a developer later on associates it with a solution or a bug report. In the former case, the user gets direct feedback on what's going on. In the latter, he will at least get a concise email - at least that's what I have in mind (and I think Niko as well). The big difference to our current solution is just that users get far less emails, like bug XYZ marked as duplicate. Or mails for developer discussions in bug reports, something that most users won't understand anyways. Hmm, indeed, looks like I got carried out there, sorry about that. And yeah, I agree with that there should be a way to give a clear message to the users. Not sure whether this would work, more manual work all around while the triagers are already overloaded afaik. As much as possible should be done automatically. Though I think the duplicate detector in DrKonqi works quite well nowadays and doesn't allow even submit duplicate crashes. Hum how is this more work? Actually I cannot see how this can create more work, if at all only the same amount. On the contrary I think Niko's proposal can reduce the workload! The reason is that users should then - in theory - get a concise, short and readable instruction that should explain them how to fix their crash. Update to version XYZ for example. Keeping up the information in two separate databases wouldn't do good was my ppint. But yeah, perhaps b.k.o should have some kind of separate field for that kind of information, which would be then given out as needed. Even in KDevelop, an app where our userbase should be somewhat proficient with the whole development process, we get tons of emails because people add their +1 crashed for me as well backtraces to some hideously old bug report. And why? Because they don't read the bug reports. Somewhere in the comments there might be a fixed by commit xyz message, but they simply don't care. If now they would see a simple this is fixed by version XYZ - please update, then it would help me personally quite much already. Yeah, agreed. In my opinion the comment section of bug entries could be even more cleaned out, to just contain comments for example. Tens of marked as duplicate of messages do not bring much more info while disturbing the real comments. Mozilla uses an extension called inline history which shows changes to bug statuses and also combine successive duplicate reports, though the process is apparently so heavy the feature is not enabled for users not logged in. Advantages over current solution: - bugs.kde.org isn't filled with duplicates Not sure if this is an issue anymore regarding to crashes. Couldn't find the blog entry related to this quickly, but here's a reviewboard entry: [6] . Anyway, the idea is good nevertheless. maybe not duplicates, but definitely about +1 crashes for me as well messages for long since fixed crashes. Hmm, yup. The traceparser makes inlined backtraces to be not so verbose, but doesn't remove the problem completely. This would be a great plus indeed, though would need adaptation on processes depending on how specific solutions should be shown to the user. If fixed-in tags or similar are set to bugs when they're fixed, that information could be easily given to user in a this bug is fixed in version x sense. or the developer takes the time to tell people he fixed the bug somewhere. seriously, that's not too much to ask of them True, perhaps a separate field could be provided, and the comment closing the bug could be used if none specified? Some things to consider: - If there would be a separate crash-site, could it be worth to allow crash reports without login? maybe in the first step, but once they found an actual crash I really think they need to provide an email for asking for feedback and such. Yup, this comment was more about not having a need to create a separate login, as I think that'll still be the barrier for getting reports. But yeah, there are two sides in this. - Data sanitation? Ubuntu doesn't reveal the crash reports per default as they might contain something which shouldn't be public. how is this related to this proposal? our current solution has the same problem and maybe/probably some kind of code in place to achieve that. Well, basically if the reporting crashes will be much easier (esp. if no login is needed) and there'll be loads of more reports, then issues might surface on this front. This was mostly food for thought though. - When getting duplicate backtraces from users the bug entry could be updated automatically with the version the crash happened, this would in my opinion be a plus in a sense that can reproduce in version x entries wouldn't flood the comment section. Anyway, this is something which could be generally
Re: Review Request: Fix KWidgetItemDelegate not updating on FocusIn and FocusOut
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104149/#review11317 --- Ship it! Ship It! - Jeremy Paul Whiting On March 4, 2012, 2:58 a.m., Daniele Elmo Domenichelli wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104149/ --- (Updated March 4, 2012, 2:58 a.m.) Review request for kdelibs. Description --- KWidgetItemDelegate does not update when the itemView gets or loses the focus. This may cause problems with the text colors of the selected indexes. I'm not sure if this is the best way to do it, since in all the other places this is done asyncronously using QTimer::singleShot(0, this, SLOT(initializeModel())), but this initializes the whole model, and I think it is not needed here. The alternatives are to update the whole model, or to add another slot to initialize only selected items. Diffs - kdeui/itemviews/kwidgetitemdelegate.cpp 828e498 Diff: http://git.reviewboard.kde.org/r/104149/diff/ Testing --- Thanks, Daniele Elmo Domenichelli
Re: DrKonqi improvement idea
On Mon, March 12, 2012 10:36 am, Thomas Zander wrote: On Sunday 11 March 2012 11.26.53 Niko Sams wrote: I'd like to talk about an idea on how DrKonqi [] What software could crashes.kde.org run? I'm not sure, maybe abugzilla installation or somethingcustom written. Or some other bugtracking software. I'd say this is a great idea, mostly because it means a lot more can be automated on lots of ends. I like this idea too. I'd also make your webpage (or site) be mostly dumb in the handling of the data its being sent and then have a continues job on the machine to actually process and handle these crash reports. So if we get loads of requests in, we just store the data to be processed when there is CPU available. The reason is that I think we get much more useful information out of this if we allow it to take more time than a webrequest would allow. And also this will make the site much more responsive and painless. It just scales better ;) There would be an advantage in giving instant feedback to the user if possible, but if that turns out to be impractical, Thomas's suggestion of using background processing on the server could be sensible. I think Niko's proposal points to a deficiency in the current bug reporting system, in that the current system doesn't provide a facility to present the user with a quick summary of actions to take to resolve/work around the bug. True, it does have the 'version fixed in' field for bugs which are fixed, but there's nowhere that the developer can enter workarounds etc. without them being lost in the bug discussion. I'd suggest an extra text field called 'User action summary' at the top of the bug report, under 'version fixed in'. Its purpose would be to give a brief summary of how to avoid the bug (upgrade to version x.y.z / any workarounds / etc.) or what is required from users to investigate it (e.g. a summary of information needed). Reference could be made in the summary to individual comments in the bug report. The user action summary should only be editable by the assignee, to prevent users taking it upon themselves to enter mistaken information. This field could serve two purposes: 1) It would enable users to see at a glance what the status of the bug is, even in a bug report containing long winded discussion or lots of duplicate reports. 2) It could be used when crash reporting, to provide the user-intelligible feedback which Niko is proposing. In this case, of course, there would need to be a link between any crashes.kde.org and bugs.kde.org. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: DrKonqi improvement idea
On Sun, Mar 11, 2012 at 13:57, henry miller h...@millerfarm.com wrote: Good ideas, if anyone actually implements it. A couple of comments. Most users are not programmers - they will not know how to recogize similear backtraces are the same root cause. Worse I know of many cases where I - a programmer - was wrong. The more automated detection we can do the better. In fact many random crashes have been traced down to the same root cause, so we really need the ability to check the user's config in a distribution specific way. If some misconfiguration is found we can ignore the backtrace. DrKonqi already detects duplicates, which works pretty good usually. But there is still room for improvement... Niko
Re: Re: DrKonqi improvement idea
On Mon, Mar 12, 2012 at 19:34, Martin Gräßlin mgraess...@kde.org wrote: On Monday 12 March 2012 19:26:27 Niko Sams wrote: On Sun, Mar 11, 2012 at 13:57, henry miller h...@millerfarm.com wrote: Good ideas, if anyone actually implements it. A couple of comments. Most users are not programmers - they will not know how to recogize similear backtraces are the same root cause. Worse I know of many cases where I - a programmer - was wrong. The more automated detection we can do the better. In fact many random crashes have been traced down to the same root cause, so we really need the ability to check the user's config in a distribution specific way. If some misconfiguration is found we can ignore the backtrace. DrKonqi already detects duplicates, which works pretty good usually. But there is still room for improvement... *cough* https://bugs.kde.org/report.cgi?x_axis_field=resolutiony_axis_field=z_axis_field=query_format=report- tableshort_desc_type=allwordssubstrshort_desc=product=kwinbug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_status=RESOLVEDbug_status=NEEDSINFObug_status=VERIFIEDbug_status=CLOSEDlongdesc_type=allwordssubstrlongdesc=bug_file_loc_type=allwordssubstrbug_file_loc=keywords_type=allwordskeywords=bug_id=bug_id_type=anyexactvotes=votes_type=greaterthaneqbug_severity=crashemailassigned_to1=1emailtype1=substringemail1=emailassigned_to2=1emailreporter2=1emailcc2=1emailtype2=substringemail2=emailtype3=substringemail3=chfield=[Bug+creation]chfieldvalue=chfieldfrom=2011-01-01chfieldto=Nowj_top=ANDf1=noopo1=noopv1=format=tableaction=wrap That's the stats for all crash reports reported against kwin since 01/01/2011 and now. It illustrates nicely one of the major problems of DrKonqui: you can report the duplicates. Of course KWin is the worst case scenario for measuring DrKonqui as we have all those nice driver bugs ;-) wow, you poor guy :D Well then KWin would profit a lot! And finding duplicates should be done server side, so it can be improved without having to wait for DrKonqi getting updated. Niko
Re: Re: Re: DrKonqi improvement idea
On Monday 12 March 2012 19:39:12 Niko Sams wrote: On Mon, Mar 12, 2012 at 19:34, Martin Gräßlin mgraess...@kde.org wrote: On Monday 12 March 2012 19:26:27 Niko Sams wrote: On Sun, Mar 11, 2012 at 13:57, henry miller h...@millerfarm.com wrote: Good ideas, if anyone actually implements it. A couple of comments. Most users are not programmers - they will not know how to recogize similear backtraces are the same root cause. Worse I know of many cases where I - a programmer - was wrong. The more automated detection we can do the better. In fact many random crashes have been traced down to the same root cause, so we really need the ability to check the user's config in a distribution specific way. If some misconfiguration is found we can ignore the backtrace. DrKonqi already detects duplicates, which works pretty good usually. But there is still room for improvement... *cough* https://bugs.kde.org/report.cgi?x_axis_field=resolutiony_axis_field=z_ax is_field=query_format=report- tableshort_desc_type=allwordssubstrshort_desc=product=kwinbug_status UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_sta tus=RESOLVEDbug_status=NEEDSINFObug_status=VERIFIEDbug_status=CLOSEDlo ngdesc_type=allwordssubstrlongdesc=bug_file_loc_type=allwordssubstrbug_ file_loc=keywords_type=allwordskeywords=bug_id=bug_id_type=anyexactvo tes=votes_type=greaterthaneqbug_severity=crashemailassigned_to1=1email type1=substringemail1=emailassigned_to2=1emailreporter2=1emailcc2=1em ailtype2=substringemail2=emailtype3=substringemail3=chfield=[Bug+creat ion]chfieldvalue=chfieldfrom 11-01-01chfieldto=Nowj_top=ANDf1=noop o1=noopv1=format=tableaction=wrap That's the stats for all crash reports reported against kwin since 01/01/2011 and now. It illustrates nicely one of the major problems of DrKonqui: you can report the duplicates. Of course KWin is the worst case scenario for measuring DrKonqui as we have all those nice driver bugs ;-) wow, you poor guy :D Well then KWin would profit a lot! yes, indeed and I must say that I think your idea is great. If a project gets started I will support it, just to get to the point where we can tell users: click foo than bar to disable baz and the crash is gone :-) Cheers Martin And finding duplicates should be done server side, so it can be improved without having to wait for DrKonqi getting updated. Niko signature.asc Description: This is a digitally signed message part.
Re: DrKonqi improvement idea
On Mon, Mar 12, 2012 at 09:54, Milian Wolff m...@milianw.de wrote: On Monday 12 March 2012 02:14:00 Teemu Rytilahti wrote: - When getting duplicate backtraces from users the bug entry could be updated automatically with the version the crash happened, this would in my opinion be a plus in a sense that can reproduce in version x entries wouldn't flood the comment section. Anyway, this is something which could be generally 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?! yeah, those people commenting after every release that the bug is still not (magically) fixed :D - 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?! I would store all crashes, also duplicates - maybe it's a false positive (that's what Teemu is talking about I think) - it's an important fact to see how common a crash is Niko
Re: DrKonqi improvement idea
On Mon, Mar 12, 2012 at 01:14, Teemu Rytilahti t...@iki.fi wrote: This really depends on how it'd be used, but perhaps yeah, this might be a good idea indeed. This is something I encountered while working on a course paper earlier this semester. Similar systems are up there for Mozilla (Socorro[1], shown in here [2], Microsoft [3] and Ubuntu too. I bet that LibreOffice might have something similar too, but haven't looked into that. Interesting. But no system provides a solution I think. Socorro looks very powerful - but they need to process much more crashes. - user posts the crash, crashes.kde.org doesn't find a duplicate. User gets the possibility to subscribe to updates for this crash to get an email when a solution for his crash was entered by the developers I don't like the idea of having a separate place for comments and/or solutions, but that's just me. In my opinion the commenting could happen in a valid b.k.o entry as needed. Sounds good. One place is enough and fragmentation would be bad. - 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. - 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. Niko
Re: DrKonqi improvement idea
On Mon, Mar 12, 2012 at 17:32, Thomas Zander zan...@kde.org wrote: On Monday 12 March 2012 16.20.00 David Jarvie wrote: There would be an advantage in giving instant feedback to the user if possible, but if that turns out to be impractical, Thomas's suggestion of using background processing on the server could be sensible. I was thinking about this a bit longer today and we[1] might do something smart like letting the webapp generate a url thats unique for this person , or the report and that url is his status page that will then get updated when something new happens. A plasma app can use polling at regular intervals to then show the user how his report progresses, including links to suggestions like fixed in ver xyz or workarounds like; don't use files with å or é in them.. Well, we have to see how fast a duplicate search can be done. Maybe there could be a quick search that provides a immediate solution (if available) and a better slower background search. Niko
Re: DrKonqi improvement idea
On Mon, Mar 12, 2012 at 11:36, Thomas Zander zan...@kde.org wrote: On Sunday 11 March 2012 11.26.53 Niko Sams wrote: I'd like to talk about an idea on how DrKonqi [] What software could crashes.kde.org run? I'm not sure, maybe abugzilla installation or somethingcustom written. Or some other bugtracking software. I'd say this is a great idea, mostly because it means a lot more can be automated on lots of ends. Naturally, the actual automation means research and development, which means manpower. I didn't get from your email if you wanted to volunteer for some of this work :) Personally I'd go for a solution that also tries to register the last 20 keystrokes and 20 mouse clicks (qt global event listener) and if and when a crash occurs that info can be send with the backtrace. So even if there are no debug packages installed we get some info to do data-mining on. That would provide useful information? I guess it depends on the application and bug. Either case, I'd think you want something custom written. Its not too much work to do the basics and maybe we can steal some code that compares backtraces and steal some ideas or code for on-disk data-store of those backtraces. +1 The existing solutions are very complex and have lots of features. And they solve different use cases. Niko, I'm wondering if you can help out with realization of your ideas, and if you have php or perl skills for instance. I might find some time on my hands, and it sounds like a fun (and needed) project so I could help out. I would have php skills, but I don't have that much spare time. But with the positive feedback so far I think I will start with something. Niko
Re: Review Request: Limit KDateComboBox date keywords to the date range set for the widget
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104198/#review11343 --- Ship it! Ship It! - John Layt On March 8, 2012, 11:04 p.m., David Jarvie wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104198/ --- (Updated March 8, 2012, 11:04 p.m.) Review request for kdelibs and John Layt. Description --- Currently, all configured date keywords are displayed in the date picker popup, including keywords for dates which lie outside the set date range and which are therefore invalid for selection. This patch hides keywords for dates earlier than the minimum date, or later than the maximum date. This is the fix discussed at the KDEPIM meeting. Diffs - kdeui/widgets/kdatecombobox.cpp 74b54f2 Diff: http://git.reviewboard.kde.org/r/104198/diff/ Testing --- Tested using KAlarm for minimum date of today or later. Thanks, David Jarvie
Review Request: KJS/Grammar: Introduce new non-terminal IdentifierName, to handle keywords as PropertyName, in Memberexps and CallExpr
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104243/ --- Review request for kdelibs. Description --- KJS/Grammar: Introduce new non-terminal IdentifierName, which allows keywords to be used as PropertyName, in Memberexps and CallExpr. (but not yet enum,export,extends, super, because they have the same value RESERVED) Diffs - kjs/grammar.h 2a006df kjs/grammar.cpp 32dbeae kjs/grammar.y d5e835f Diff: http://git.reviewboard.kde.org/r/104243/diff/ Testing --- Tested with ecmascript262, all keyword cases pass now, except the reserved ones Thanks, Bernd Buschinski
