Re: Review Request 110687: DrKonqi should check for disabled version as the very first step in the reporting assistant.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110687/ --- (Updated June 5, 2013, 10:05 a.m.) Review request for KDE Runtime and George Kiagiadakis. Changes --- Fix spelling and grammer errors Description --- As I have said in https://bugs.kde.org/show_bug.cgi?id=315073#c3 , Bugzilla's new and nice behavior (since 4.2.5) of rejecting reports against disabled versions brings a new usability problem to DrKonqi: users spend value time in downloading debug symbols, generating the backtrace, writing all information he/she can recall, but in the end only to find an error dialog telling them (in a not so clear and friendly way) that bugs.kde.org won't accept his/her report. I would propose making version checking the very first step in the reporting assistant: a perfect bug report against an outdated version is still useless. The patch has been created for sometime and works, but unfortunately I don't have much time for coding since then, so it is not as good as what I have planned to make it to be. Nevertheless, I think it is still a good improvement of the current situation. This addresses bug 315073. http://bugs.kde.org/show_bug.cgi?id=315073 Diffs (updated) - drkonqi/CMakeLists.txt 39833d7 drkonqi/drkonqi_globals.h d5f098a drkonqi/productmapping.h f926c9d drkonqi/productmapping.cpp f4e59e5 drkonqi/reportassistantdialog.cpp c296059 drkonqi/reportassistantpages_bugzilla_versioncheck.h PRE-CREATION drkonqi/reportassistantpages_bugzilla_versioncheck.cpp PRE-CREATION drkonqi/reportinterface.h c7e374e drkonqi/reportinterface.cpp 4190c40 drkonqi/ui/assistantpage_versioncheck.ui PRE-CREATION Diff: http://git.reviewboard.kde.org/r/110687/diff/ Testing --- File Attachments rejecting disabled version http://git.reviewboard.kde.org/media/uploaded/files/2013/05/28/drkonqi-version-checking.png reject disabled versions (revised edition) http://git.reviewboard.kde.org/media/uploaded/files/2013/05/30/bugzilla-version-cheking-improved.png Thanks, Jekyll Wu
Re: Techbase: schedules for playground and extragear
Albert Astals Cid wrote: El Dimarts, 4 de juny de 2013, a les 23:35:17, Sven Brauch va escriure: If there are no objections, I'd remove the two pages mentioned above by the end of the week. What do you think? I think I found those pages recently too, and I'm all for deleting them. They will get out of date again, even if someone would update them now. Cheers! The idea is to have a centralized point of information for all the software, of course if maintainers ignore the page it won't work. I'd rather have people care about the page than delete it, but as making people care is hard, sure go ahead and kill it. This is really sad. If each project has a dedicated page for this, would it be possible to link the relevant pages? A proper solution for this is most probably the integration of calendars on projects.kde.org and the main KDE calendar, but this requires time. A simpler solution is to remind maintainers about the existence of the shared KDE calendar, not sure who can write there. Ciao -- Luigi
Re: Review Request 110043: Proposed fix/workaround for legacy encoded filename handling
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110043/#review33783 --- Would anybody please take a look at the latest version and comment? - Róbert Szókovács On May 17, 2013, 10:08 a.m., Róbert Szókovács wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110043/ --- (Updated May 17, 2013, 10:08 a.m.) Review request for kdelibs and Thiago Macieira. Description --- This patch works around the problem of filenames that are not valid UTF8 strings: in KLocalePrivate::initFileNameEncoding() KDE sets the QFile's encoding/decoding function, to to/fromUTF8() in QString, which in turn calls QUtf8's converter function (QUtf8 is not exported to developers, so I had to use an inefficient method, I think it would be better if we could use the state parameter for error detection). I replaced this with the said functions' copy/pasted version and changed it, so when it encounters an invalid UTF8 string, it will encode it byte by byte, mapping the lower 128 their normal unicode place and the upper 128 to U+18000-U+1807F, and of course the decoder reverses it. To make this actually work you have to define the KDE_UTF8_FILENAMES enviroment variable to a specific value (broken_names). To test it, do the following: .kde/env/KDE_UTF8_FILENAMES.sh with this content: export KDE_UTF8_FILENAMES=broken_names logout, login, try dolphin on faulty files. (instead of the usual boxed ? you'll see just boxes) This addresses bug 165044. http://bugs.kde.org/show_bug.cgi?id=165044 Diffs - kdecore/localization/klocale_kde.cpp b010e74 Diff: http://git.reviewboard.kde.org/r/110043/diff/ Testing --- Thanks, Róbert Szókovács
Re: Techbase: schedules for playground and extragear
I'm not terribly involved here as I don't maintain anything in extragear or work on translations of such, but I agree with Luigi that if there are schedules for each of those projects elsewhere we ought to replace that page's content with links to the places that have the official schedules. My 2c, Jeremy On Wed, Jun 5, 2013 at 10:23 AM, Eike Hein h...@kde.org wrote: On Tuesday 04 June 2013 23:50:26 Albert Astals Cid wrote: The idea is to have a centralized point of information for all the software, of course if maintainers ignore the page it won't work. I'd rather have people care about the page than delete it, but as making people care is hard, sure go ahead and kill it. AFAIK the purpose of those pages is mostly so our translation teams have a central place to find out when projects are plan- ning a release so they can prioritize their efforts. I don't see how many maintainers ignoring it is a good reason to delete them as long as the maintainers who don't ignore it provide some value to the translators by doing so. Cheers, Albert Cheers, Eike
