Re: libicu dependancy
On 2023-09-17 20:59, Michael Reeves wrote: Is libicu in the CI images already? Hi, i assume for Qt it is there, but is there a need to use it directly? Qt should provide a lot of stuff that allows to skip that. Greetings Christoph
Re: KDE Builder: request for review
On 2024-07-12 23:01, Thiago Masato Costa Sueto wrote: Hi, I'd like to ask about the status of the KDE Review for kde-builder. The existing issue tracking this has been without activity for a while: https://invent.kde.org/sdk/kde-builder/-/issues/84 So far ashark seems to have fulfilled what was asked of them, and I believe they're just waiting for some confirmation on whether the project has passed KDE Review or not, and if not what else is needed to do so. The only possible issue I can see is https://invent.kde.org/sdk/kdesrc-build/-/merge_requests/376, which is moreso about kdesrc-build. Ashark has been pretty willing to address any remaining issues (technical or community related) so far, and they've been very active on Matrix helping new users. From my part, I need the project to get an ack first before I can make tutorials for it. Hi, I think before we promote this more as 'the tool to use' it would be nice to get some proper review flow going to avoid we run again into incompatible changes. These got me now several times and if we promote this to be used and write howtos the goal must be in my eyes no further backward incompatible changes or large dependency increases without a real good reason. But that is just my viewpoint. Greetings Christoph Thiago
Re: KDE Builder: request for review
On 2024-07-13 15:52, christ...@cullmann.io wrote: On 2024-07-12 23:01, Thiago Masato Costa Sueto wrote: Hi, I'd like to ask about the status of the KDE Review for kde-builder. The existing issue tracking this has been without activity for a while: https://invent.kde.org/sdk/kde-builder/-/issues/84 So far ashark seems to have fulfilled what was asked of them, and I believe they're just waiting for some confirmation on whether the project has passed KDE Review or not, and if not what else is needed to do so. The only possible issue I can see is https://invent.kde.org/sdk/kdesrc-build/-/merge_requests/376, which is moreso about kdesrc-build. Ashark has been pretty willing to address any remaining issues (technical or community related) so far, and they've been very active on Matrix helping new users. From my part, I need the project to get an ack first before I can make tutorials for it. Hi, I think before we promote this more as 'the tool to use' it would be nice to get some proper review flow going to avoid we run again into incompatible changes. These got me now several times and if we promote this to be used and write howtos the goal must be in my eyes no further backward incompatible changes or large dependency increases without a real good reason. But that is just my viewpoint. Hi, any feedback on that? Thanks. Greetings Christoph Greetings Christoph Thiago
Re: KDE Builder: request for review
Hi, On 2024-07-15 20:13, Andrew Shark wrote: You mean new python dependencies? I never added them. Oppositely, I reduce them. For example, I gladly got rid of the "promise" dependency. yes, with dependencies I meant Python libs and the Python version. There was some rather lengthy discussions before we arrived at the current OK situation. Regarding reviews, I am not against them. I just continue directly committing changes that do not influence on the behavior, such as for example, changes to follow pep8 rules and refactorings. There were incompatible changes in the last months and I would really like to have a proper review process for larger changes in general. And I think it must be clear that the top priority must be to stay compatible. If I write a howto now, I want that it still works in 2 years. That doesn't mean there shall be no new features, just not breaking changes. Like we do it with Frameworks and Co. or how CMake handles that. The build tool shall not require the user to fixup the config without really good reasons. Greetings Christoph (please keep the list in CC) Hi, I think before we promote this more as 'the tool to use' it would be nice to get some proper review flow going to avoid we run again into incompatible changes. These got me now several times and if we promote this to be used and write howtos the goal must be in my eyes no further backward incompatible changes or large dependency increases without a real good reason. But that is just my viewpoint. Hi, any feedback on that? Thanks.
Re: Crow Translate
On 2024-07-17 17:07, Hennadii Chernyshchyk wrote: Added it to the readme and to the app metadata. Unsure about adding it to the application as well, I don't like popups, even one-timers... But I will add it to the app if you or anyone else will insist on it. Hi, I think it should be in the app, either as inline message widget or popup, one can not expect that users need to read the meta data somewhere. We try to be privacy sensitive, once telling that the data will float around the internet is really important in my eyes. Greetings Christoph
Re: KDE Builder: request for review
Hi, On 2024-07-15 21:50, christ...@cullmann.io wrote: Hi, On 2024-07-15 20:13, Andrew Shark wrote: You mean new python dependencies? I never added them. Oppositely, I reduce them. For example, I gladly got rid of the "promise" dependency. yes, with dependencies I meant Python libs and the Python version. There was some rather lengthy discussions before we arrived at the current OK situation. Regarding reviews, I am not against them. I just continue directly committing changes that do not influence on the behavior, such as for example, changes to follow pep8 rules and refactorings. There were incompatible changes in the last months and I would really like to have a proper review process for larger changes in general. And I think it must be clear that the top priority must be to stay compatible. If I write a howto now, I want that it still works in 2 years. That doesn't mean there shall be no new features, just not breaking changes. Like we do it with Frameworks and Co. or how CMake handles that. The build tool shall not require the user to fixup the config without really good reasons. Greetings Christoph (please keep the list in CC) any feedback on that? Greetings Christoph Hi, I think before we promote this more as 'the tool to use' it would be nice to get some proper review flow going to avoid we run again into incompatible changes. These got me now several times and if we promote this to be used and write howtos the goal must be in my eyes no further backward incompatible changes or large dependency increases without a real good reason. But that is just my viewpoint. Hi, any feedback on that? Thanks.
Re: Licensing for cxx-kde-frameworks (Rust bridge for KF6)
On 2024-11-03 23:06, Neal Gompa wrote: On Sun, Nov 3, 2024 at 4:30 PM Darshan Phaldesai wrote: On 31/10/24 5:47 am, Sune Vuorela wrote: > On 2024-10-30, Darshan Phaldesai wrote: >> Few considerations: >> First, I plan to include bridges for most libraries needed for >> application development and so need to consider their licenses as well. >> Second, This project will only hold the "bridge" code and thus users >> will still need to install the libraries. I don't think this should >> cause any license violations but the bridge code is based of the method >> signatures of the original libraries. >> Third, Upstream `cxx-qt` project uses Apache-2.0+MIT and I planned to do >> the same but KDE's Licensing policy doesn't mention any thing about >> Apache-2.0. > I'd say just stick the same license on it as the KDE Frameworks in > question. > Given they are a directly derived work and also uses the KDE Frameworks > underneath, giving any other license is just going to be confusing for > the people involved. > > The app developers needs to deal with (l)gpl licenses anyway. > > /Sune Now that I think about it, this might the best way to maintain license compatibility. Individual bridges can be licensed depending on their counterparts. I will make this change. Thank you. It's not that simple. The reason I suggested MPL-2.0 is because LGPL-2.1-or-later is effectively the same as GPL-2.0-or-later with Rust because it's statically linked. MPL-2.0 preserves the copyleft at a per source file level, but allows the binary artifact to have a composition of compatible licenses (including the GNU ones). This is the least messy for Rust bindings to LGPL libraries. If upstream cxx-qt uses Apache-2.0+MIT I would propose to just follow that. Greetings Christoph
Re: migrating old metadata (kdesrc-build action needed)
On 2024-11-03 19:54, Harald Sitter wrote: Ahoy Currently we have two sets of duplicated metadata one in the ksb format and one in yaml. Nico wants to only have one, and I for one agree with this. There are also some broader repo-metadata changes coming, not sure how much they impact kdesrc-build but the lack of input from the kdesrc-build side is concerning at least. So, someone should get involved on those (see the issues/MRs on repo-metadata for details). As for the duplicated metadata it's my understanding kdesrc-build needs to be updated to use these: https://invent.kde.org/sysadmin/repo-metadata/-/tree/master/build-configs?ref_type=heads Long story short: if nobody steps up and maintains kdesrc-build it will be defunct in short order. But not all is lost! kde-builder acts as replacement and is on top of the new metadata, so we are technically already covered. Hi, kde-builder in no drop in replacement, at least for me. I and others discussed that close to infinitely in the past with the kde-builder maintainer. I fail to see the issue to generate both data files. If I read https://invent.kde.org/sysadmin/repo-metadata/-/issues/2 and my input on https://invent.kde.org/sysadmin/repo-metadata/-/merge_requests/389 months ago that is no issue. Greetings Christoph HS
Re: Assistance with two bugs
On 2024-09-23 01:13, Michael Reeves wrote: I am requesting assistance with following https://bugs.kde.org/show_bug.cgi?id=489815 -- May or may not be fixable current auto updates for translations seem to quire Qt/Kde based translation calls. I fail to see this as as real world issue, can one at all measure the impact of that extra loaded DLL, I highly doubt that. I would not start to put work in replacing Qt just because somebody says loading that is slow. https://bugs.kde.org/show_bug.cgi?id=486401 -- This is a Wayland specific slow down when scrolling -- very noticeable. Greetings Christoph
Re: Request to become the maintainer of Trojitá
On 2024-09-23 22:08, Kevin Kofler wrote: Heiko Becker wrote: On Monday, 23 September 2024 21:52:38 CEST, Kevin Kofler wrote: Hi, I would like to request unarchiving the Trojitá project and assigning maintainership to me. I like to get it back, too. Are you willing to maintain it together with me? I am fine with any helping hands (at least trusted KDE contributors who I can trust to not attempt to plant backdoors ;-) ). Kevin Kofler For the archiving see https://invent.kde.org/sysadmin/repo-metadata/-/issues/23 It is one click to unarchive it and if somebody ports it, that is great! Greetings Christoph
Re: Sunsetting Qt 5
On 2024-11-30 11:51, Albert Astals Cid wrote: El dissabte, 30 de novembre del 2024, a les 4:57:10 (Hora estàndard del Centre d’Europa), Ben Cooksley va escriure: HI all, This past week or so i've been dealing with a number of issues relating to a handful of still Qt 5 based projects trying to make use of updated dependencies. These issues have revealed that the level of support for Qt 5 as a platform in general is now subject to a significant degree of bit-rot. As such, we need to set a point at which we consider Qt 5 to no longer be supported. To start I would like to remove support for all CD builds (Windows, Appimage, macOS) as well as CI support for Windows. There is already a general view in Craft that Qt 5 is unmaintained and this removal simply reflects that. If the Craft maintainers don't want to maintain Qt5 and no one steps up I guess that's understandable. Additionally, several recent attempts to update our Windows Qt 5.15 images, based on MSVC 2019, have all failed due to various different changes (with the build of MPFR breaking for reasons unknown - likely MSys2 updates - and QXMPP failing to build yet again) which is not a tenable position for a "CI supported" platform. That removal is proposed to be essentially immediately (ie. now). Subsequent to that I would also like to forbid any further feature releases to be made of Qt 5 software following the end of this calendar year, to clearly signal to the involved developers that they need to work on getting a Qt 6 release out. Patch releases to resolve bugs and security issues could continue to be made for a period of 6 more months at most. This is not acceptable. Qt 5.0 was released in December 2012 We introduced KDE Frameworks 5 in July 2014 https://kde.org/announcements/frameworks/5/5.0.0/ We stopped accepting kdelibs4 based apps in the "was-KDE-Gears-back-then" in December 2017 https://community.kde.org/Schedules/Applications/17.12_Release_Schedule Qt 6.0 was released in December 2020 We introduced KDE Frameworks 6 in February 2024 If we do the diff against our KF6 release we should accept KF5 apps in KDE Gear at least until 2027, if you count since Qt relase we need to accept them until end of 2025. Giving 1 month of heads up is not ok. One month is not long enough. I would propose to set some 25.xx deadline for that, like one of the Gear releases there. But just to be sure, about how many applications on invent do we talk. Greetings Christoph Cheers, Albert Any application that does not have a port underway as at the point where feature releases become forbidden is proposed to be archived as unmaintained at that time, with the same fate befalling applications that have an unreleased port branch on 1 July 2025. Should at any point post-31 December 2024 there become issues that make Qt 5 CI unsustainable for the remaining platforms (Linux and FreeBSD) then we would discontinue CI for them at that time as well with minimal notice being given in advance. Note that while this may seem a little "over the top" it is necessary to reduce the maintenance burden and cost of keeping Qt 5 alive (for an ever decreasing number of applications) on the maintainers of central infrastructure (such as myself). Regards, Ben
[kcalc][kcharselect][kcron] Merged frameworks branch to master, now KF5 based
Hi, I just merged the "frameworks" KF5 porting branches of the following applications to "master" branch: - kcalc - kcharselect - kcron These applications will be released as KF5 applications for the KDE Applications 15.03 release. Please check if everything went smooth, and report issues/regressions to bugs.kde.org. Also, I have no administrative powers to make the required changes to our infrastructures, so if not already done, please help with rewiring CI, translations, pko, etc. Thanks to Lukáš Tinkl and Laurent Montel for help with porting. I am still amazed how Laurent manages to find the time while busy with PIM. Christoph Feck (kdepepo)
Re: Feature matrix for future infrastructure
On Thursday 29 January 2015 00:10:02 Jan Kundrát wrote: > It will be even easier -- the upcoming Gerrit 2.11 contains an > online editor, so the workflow will be "open file, edit it, push a > button for making a change request". If it even allows to edit a change request from a different person online, then I *want that*. I find it much more time consuming and demotivating to nitpick small style/whitespace changes, than to simply edit them out. Christoph Feck (kdepepo)
Re: Another proposal for modernization of our infrastructure
On Saturday 31 January 2015 20:07:42 Eike Hein wrote: > [...] Qt is using gerrit and we intend to remain a major stakeholde > in Qt development, which means a sizable number of KDE developers > need to be familiar with gerrit anyway [...] Excuse me, but if KDE developers will have to follow equivalent steps as described at http://qt-project.org/wiki/Setting-up-Gerrit to contribute, then I predict another big loss of developers. Christoph Feck (kdepepo)
Re: Review Request 122341: Port Thumbnail KIO Slave Away from KDELibs4Support
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122341/#review75101 --- thumbnail/thumbnail.cpp <https://git.reviewboard.kde.org/r/122341/#comment51969> Please do not use "//" on every line to disable a section of code. It touches every line in the git change log. Better use "#if" on a separate line. - Christoph Feck On Jan. 31, 2015, 6:24 p.m., David Narváez wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/122341/ > --- > > (Updated Jan. 31, 2015, 6:24 p.m.) > > > Review request for kde-workspace, Bhushan Shah and David Faure. > > > Repository: kio-extras > > > Description > --- > > Only major difference would be the lack of fallback to KFMI. Maybe we could > implement thumbnail features in KFileMetadata? > > > Diffs > - > > thumbnail/thumbnail.cpp 39e8de5 > > Diff: https://git.reviewboard.kde.org/r/122341/diff/ > > > Testing > --- > > Only tested compilation. > > > Thanks, > > David Narváez > >
Help solving this month's "Bug of the Month"
Hi developers! The KDE Gardening Team nominates one particular annoying bug as “The Bug of the Month”, see https://community.kde.org/Gardening This time, we need someone who can investigate a problem with keyboard shortcuts when a certain order of keyboard layouts is used: https://bugs.kde.org/show_bug.cgi?id=309193 According to recent comments, this is bug is still reproducible for some users, but not for others. It is unclear if the actual issue is in KDE software, Qt libraries, xorg libraries, or the keyboard layout definition files. Please help solving it, by adding ideas or patches to the relevant pages, review requests, or bugzilla pages. Anyone is invited to participate and our users will appreciate this bug getting solved. Suggestions for next month's bug to the kde-gardening mailing list. Thanks in advance! -- Christoph Feck http://kdepepo.wordpress.com/ KDE Quality Team
Re: Help solving this month's "Bug of the Month"
On Wednesday 04 February 2015 21:51:53 Albert Astals Cid wrote: > El Dimecres, 4 de febrer de 2015, a les 18:06:23, Martin Sandsmark > va > > escriure: > > On Wed, Feb 04, 2015 at 04:45:26PM +0100, Christoph Feck wrote: > > > According to recent comments, this is bug is still reproducible > > > for some users, but not for others. It is unclear if the > > > actual issue is in KDE software, Qt libraries, xorg libraries, > > > or the keyboard layout definition files. > > > > From reading the latest comments on that bug, and the linked Qt > > bug report, it seems pretty clear-cut to be a Qt bug that's > > fixed in Qt5, but not in Qt4? > > > > So maybe it should just be marked as an upstream bug? > > Even if it's an upstream bug, in my opinion the > BugOfTheMonth+GardeningEffort is showing the users that we care, > and if they are affected by a severe bug we're going to try to > make as much as we can to fix it, not just toss it over the fence > and say "it's not us". > > Cheers, > Albert Exactly. Looking at current Plasma 5+Qt 5 bugs, we still need to support KDE 4 users for some time. And as explained at https://community.kde.org/Gardening/BugOfTheMonth we actually want to find developers who are able to investigate all levels of the software stack, because otherwise there will simply be no progress. Christoph Feck (kdepepo)
Re: Review Request 121361: DeviceAutomounter Settings ui texts are misleading, if not plain wrong.
> On Dec. 8, 2014, 2:15 p.m., Sebastian Kügler wrote: > > solid-device-automounter/kcm/DeviceAutomounterKCM.ui, line 45 > > <https://git.reviewboard.kde.org/r/121361/diff/1/?file=331961#file331961line45> > > > > Well, with this change, the whatsthis and I suppose the function of > > this checkbox does the exact opposite of its name. > > > > automountUnknownDevices now means "only automount know devices". > > Thomas Lübking wrote: > "automountUnknownDevices" is now labeled "Automatically mount unknown > devices" and hinted "all attached devices will be automatically mounted[, > "otherwise only remembered devices will be"] > > > > Sounds correct to me, but the automount GUI sucks. > > You've to enable automounting to get a list of four items: > - known only > - "all" (does that invoke the "known only" rule?) on login > - on plugin > - an override list > > What you indeed have is "on plugin" and "on login", multiplied by the > "seen only" rule. > And then there's an override list, with a lot of unchecked devices what > seems to suggest the above rules doesn't actually apply to most things. > > What there should be are two checkboxes: > [ ] Automount removable media when attached > [ ] Automount removable media when logging in > > each of them activating a "Device override" group which allows to > controlthe override list as well as a third checkbox > > [ ] Do not automount media that has not been mounted before > > And the following override list probably needs to be some sort of > tristate - defaulting to no override, what could be done by a leading > checkbox column which activates the override for this device itfp. Frank, are you able to propose an updated patch with the above comments addressed? - Christoph --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121361/#review71555 --- On Dec. 5, 2014, 7:06 p.m., Frank Schütte wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/121361/ > --- > > (Updated Dec. 5, 2014, 7:06 p.m.) > > > Review request for kdelibs, Solid, Christoph Feck, and Helio Castro. > > > Bugs: 243046 and 261376 > http://bugs.kde.org/show_bug.cgi?id=243046 > http://bugs.kde.org/show_bug.cgi?id=261376 > > > Repository: kde-runtime > > > Description > --- > > automounterrc has four settings: > [General] > AutomountEnabled=true > AutomountOnLogin=false > AutomountOnPlugin=false > AutomountUnknownDevices=true > > The ui text for AutomountUnknownDevices says the opposite of its > functionality. This is repaired by the patch. Login/Plugin enable/disable > overrides. I tried to clarify this a little bit. > > > Diffs > - > > solid-device-automounter/kcm/DeviceAutomounterKCM.ui 3827e95 > > Diff: https://git.reviewboard.kde.org/r/121361/diff/ > > > Testing > --- > > > Thanks, > > Frank Schütte > >
[kmplot][kturtle] merged frameworks to master
I just merged these frameworks porting branches to master: - kmplot - kturtle These applications will be released as KF5 applications (using KDELibs4Support) for the KDE Applications 15.04 release. Please help updating translations, CI etc. Christoph Feck (kdepepo)
Re: Review Request 123806: [klipper] Ignore empty / blank entries
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123806/#review80466 --- klipper/klipper.kcfg (line 32) <https://git.reviewboard.kde.org/r/123806/#comment55183> It would be immensely useful, if Klipper also showed leading/trailing whitespace, i.e. for items that aren't completely whitespace. Firefox loves to add leading whitespace when copying double-clicked text, but Klipper does not show this in the menu. - Christoph Feck On May 16, 2015, 12:40 p.m., Patrick Eigensatz wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/123806/ > --- > > (Updated May 16, 2015, 12:40 p.m.) > > > Review request for kde-workspace, KDE Usability and Patrick Eigensatz. > > > Bugs: 192922 > https://bugs.kde.org/show_bug.cgi?id=192922 > > > Repository: plasma-workspace > > > Description > --- > > [PATCH] plasma-workspace: klipper: Fix #192922 Ignore blank entries > > QString::isEmpty() is used to check if the string only consists of whitespace > characters. If it does, the creation of the HistoryStringItem fails. > > > Diffs > - > > klipper/configdialog.cpp 2fe8206 > klipper/generalconfig.ui f513e9c > klipper/historyitem.cpp 36cbe61 > klipper/klipper.h 6952b11 > klipper/klipper.cpp 798b49f > klipper/klipper.kcfg a03dd16 > > Diff: https://git.reviewboard.kde.org/r/123806/diff/ > > > Testing > --- > > > Thanks, > > Patrick Eigensatz > >
Re: Review Request 123806: [klipper] Ignore empty / blank entries
> On May 16, 2015, 4:37 p.m., Christoph Feck wrote: > > klipper/klipper.kcfg, line 32 > > <https://git.reviewboard.kde.org/r/123806/diff/3/?file=369517#file369517line32> > > > > It would be immensely useful, if Klipper also showed leading/trailing > > whitespace, i.e. for items that aren't completely whitespace. > > > > Firefox loves to add leading whitespace when copying double-clicked > > text, but Klipper does not show this in the menu. See bug 159267. - Christoph --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123806/#review80466 --- On May 16, 2015, 12:40 p.m., Patrick Eigensatz wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/123806/ > --- > > (Updated May 16, 2015, 12:40 p.m.) > > > Review request for kde-workspace, KDE Usability and Patrick Eigensatz. > > > Bugs: 192922 > https://bugs.kde.org/show_bug.cgi?id=192922 > > > Repository: plasma-workspace > > > Description > --- > > [PATCH] plasma-workspace: klipper: Fix #192922 Ignore blank entries > > QString::isEmpty() is used to check if the string only consists of whitespace > characters. If it does, the creation of the HistoryStringItem fails. > > > Diffs > - > > klipper/configdialog.cpp 2fe8206 > klipper/generalconfig.ui f513e9c > klipper/historyitem.cpp 36cbe61 > klipper/klipper.h 6952b11 > klipper/klipper.cpp 798b49f > klipper/klipper.kcfg a03dd16 > > Diff: https://git.reviewboard.kde.org/r/123806/diff/ > > > Testing > --- > > > Thanks, > > Patrick Eigensatz > >
Re: Review Request 123806: [klipper] Ignore empty / blank entries
> On May 16, 2015, 9:37 p.m., Patrick Eigensatz wrote: > > klipper/historyitem.cpp, line 91 > > <https://git.reviewboard.kde.org/r/123806/diff/5/?file=369605#file369605line91> > > > > I'm not sure if I can access "Klipper" from here. If I have a look at > > how this is done at other options then I see that they only use the > > *m_bSomeSetting* vars inside the klipper class itself. > > > > I need some help on how I should access the setting. (Pass it? Check it > > in the klipper class?) > > > > Thank you :) > > Thomas Lübking wrote: > ensure klippersettings.h is included (ie. add it, implicit inclusion is a > timebomb) and use KlipperSettings::trimBlankEntries() > > "Klipper" is a class and you cannot access a class this way. > If m_bTrimBlankEntries *was* (don't make it!) a static public member, you > could access it via Klipper::m_bTrimBlankEntries (after including klipper.h > here) > > You're btw. expected to compile the changes. > Een reviews will easily oversee missing semicolons etc. - compilers do a > far better job itr. ;-) > > Patrick Eigensatz wrote: > Ah, I thougth we would load the settings from KlipperSettings:: into > Klipper - an instance of the *klipper* class - and then never use it again. > If I can simply include klippersettings.h and get the value > from there, that's fine. Thank you! > > Yes, I'm very sorry about this. I've spent hours and nights configuring > kdesrc-build and I've tried to compile klipper in a Kubuntu-VM, followed the > whole Plasma/Building guide - still didn't work. > Now trying with cmake ;) > > Patrick Eigensatz wrote: > Just a small resumé: > 1) Create an option "NAME" to simplify the strings using > QString::simplify() > 2) This option is enabled by default > > > We only need to find a name for this option. I wouldn't enable this option by default. The default should be pasting what was copied. Also, please do not mix options that affect the actual clipboard contents and the representation in the menu. An option that says "Replace whitespace with symbols" is highly confusing next to an option that says "Trim whitespace". - Christoph --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123806/#review80490 --- On May 16, 2015, 9:31 p.m., Patrick Eigensatz wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/123806/ > --- > > (Updated May 16, 2015, 9:31 p.m.) > > > Review request for kde-workspace, KDE Usability and Patrick Eigensatz. > > > Bugs: 159267 and 192922 > https://bugs.kde.org/show_bug.cgi?id=159267 > https://bugs.kde.org/show_bug.cgi?id=192922 > > > Repository: plasma-workspace > > > Description > --- > > [PATCH] plasma-workspace: klipper: Fix #192922 Ignore blank entries > > QString::isEmpty() is used to check if the string only consists of whitespace > characters. If it does, the creation of the HistoryStringItem fails. > > > Diffs > - > > klipper/generalconfig.ui f513e9c > klipper/historyitem.cpp 36cbe61 > klipper/klipper.h 6952b11 > klipper/klipper.cpp 798b49f > klipper/klipper.kcfg a03dd16 > > Diff: https://git.reviewboard.kde.org/r/123806/diff/ > > > Testing > --- > > > Thanks, > > Patrick Eigensatz > >
Re: Review Request 123806: [klipper] Ignore empty / blank entries
> On May 16, 2015, 9:37 p.m., Patrick Eigensatz wrote: > > klipper/historyitem.cpp, line 91 > > <https://git.reviewboard.kde.org/r/123806/diff/5/?file=369605#file369605line91> > > > > I'm not sure if I can access "Klipper" from here. If I have a look at > > how this is done at other options then I see that they only use the > > *m_bSomeSetting* vars inside the klipper class itself. > > > > I need some help on how I should access the setting. (Pass it? Check it > > in the klipper class?) > > > > Thank you :) > > Thomas Lübking wrote: > ensure klippersettings.h is included (ie. add it, implicit inclusion is a > timebomb) and use KlipperSettings::trimBlankEntries() > > "Klipper" is a class and you cannot access a class this way. > If m_bTrimBlankEntries *was* (don't make it!) a static public member, you > could access it via Klipper::m_bTrimBlankEntries (after including klipper.h > here) > > You're btw. expected to compile the changes. > Een reviews will easily oversee missing semicolons etc. - compilers do a > far better job itr. ;-) > > Patrick Eigensatz wrote: > Ah, I thougth we would load the settings from KlipperSettings:: into > Klipper - an instance of the *klipper* class - and then never use it again. > If I can simply include klippersettings.h and get the value > from there, that's fine. Thank you! > > Yes, I'm very sorry about this. I've spent hours and nights configuring > kdesrc-build and I've tried to compile klipper in a Kubuntu-VM, followed the > whole Plasma/Building guide - still didn't work. > Now trying with cmake ;) > > Patrick Eigensatz wrote: > Just a small resumé: > 1) Create an option "NAME" to simplify the strings using > QString::simplify() > 2) This option is enabled by default > > > We only need to find a name for this option. > > Christoph Feck wrote: > I wouldn't enable this option by default. The default should be pasting > what was copied. > Also, please do not mix options that affect the actual clipboard contents > and the representation in the menu. An option that says "Replace whitespace > with symbols" is highly confusing next to an option that says "Trim > whitespace". > > Kai Uwe Broulik wrote: > Btw I just pushed the highlight feature to the Klipper plasmoid and I > don't see why that one should be configurable. > > Thomas Pfeiffer wrote: > >I wouldn't enable this option by default. The default should be pasting > what was copied. > > Please explain what ordinary users would need extra whitespace at the > beginning or end of a selection for. > > > Also, please do not mix options that affect the actual clipboard > contents and the representation in the menu. An option that says "Replace > whitespace with symbols" is highly confusing next to an option that says > "Trim whitespace". > > Btw I just pushed the highlight feature to the Klipper plasmoid and I > don't see why that one should be configurable. > > Makes sense. Just one option for trimming, then. If it's not trimmed, > it's replaced. I agree that there's no reason why one would not want the > whitespace visualized in a better way. > Please explain what ordinary users would need extra whitespace at the > beginning or end of a selection for. When reordering words in a text-editor, I cut/paste them including a space, otherwise I end up with wrong (double or missing) spaces. - Christoph --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123806/#review80490 --- On May 16, 2015, 9:31 p.m., Patrick Eigensatz wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/123806/ > --- > > (Updated May 16, 2015, 9:31 p.m.) > > > Review request for kde-workspace, KDE Usability and Patrick Eigensatz. > > > Bugs: 159267 and 192922 > https://bugs.kde.org/show_bug.cgi?id=159267 > https://bugs.kde.org/show_bug.cgi?id=192922 > > > Repository: plasma-workspace > > > Description > --- > > [PATCH] plasma-workspace: klipper: Fix #192922 Ignore blank entries > > QString::isEmpty() is used to check if the string only consists of whitespace > characters. If it does, the creation of the HistoryStringItem fails. > > > Diffs > - > > klipper/generalconfig.ui f513e9c > klipper/historyitem.cpp 36cbe61 > klipper/klipper.h 6952b11 > klipper/klipper.cpp 798b49f > klipper/klipper.kcfg a03dd16 > > Diff: https://git.reviewboard.kde.org/r/123806/diff/ > > > Testing > --- > > > Thanks, > > Patrick Eigensatz > >
KDE Applications Versioning
Hi, for frameworks, it is all very nice and automatic, the version in the CMakeLists.txt get auto-updated on each KF 5.x release. It seems to me, for the "applications" collection, something similar might make sense. E.g. I missed to ever update the Kate version since 5.0 and other applications like Dolphin and Konsole seem to have similar problems. Would it make sense to have some "we auto-define some version CMake var" to KDE Application release number? For e.g. bug reports that would make all things easier. Or do I miss some magic already in place (e.g. the opensuse packages seems to have patched release numbers, at least for Konsole). Greetings Christoph -- ----- Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
Re: KDE Applications Versioning
> On Tue, Jun 9, 2015 at 11:35 AM, David Jarvie wrote:
>
> >
> > There has been debate about this for frameworks, and there is an argument
> > there (not agreed by everybody) for making all frameworks have the same
> > version, since framework libraries are dependencies for other software.
> >
> > The same arguments don't apply to applications, which in general are not
> > dependencies. Other than convenience for maintainers who forget to update
> > version numbers, I can see no good reason for forcing applications to have
> > a uniform version number. I prefer using the version number to reflect the
> > development status of the application (by use of major, minor and patch
> > version numbers), as in the past. This makes it easier when dealing with
> > bug reports, to know the state of the program at the version in question.
> > For maintainers who want to use some other scheme, that's also fine. The
> > important thing is to leave the choice.
> >
>
> Personally I prefer having the application versions matching the release
> version
> (ie. 15.04.x) so that there is no additional versions mapping required ("is
> version 3.4
> part of KDE Applications 15.04 or 15.08 or..?").
>
> So I for one would also welcome such feature, but can absolutely relate to
> David's
> position too; the versioning should not be forced on Applications. So this
> could be
> easily made opt-in by using some predefined CMake variable and projects
> having
> such var would get the version raised by the scripts.
>
> +1 to that idea.
Hi,
I don't want to force people to use it, just to have always existing and updated
KDE_APPLICATIONS_ variables around for people wanting to use them.
And I think it makes sense to use them for a lot apps, given not many apps have
any
real version number updates it seems ;=) (it makes bug reports much nicer, if
you can actually
track the bug to some released version)
Greetings
Christoph
--
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com
Science Park 1 Tel: +49-681-38360-22
66123 Saarbrücken Fax: +49-681-38360-20
GERMANYWWW: http://www.AbsInt.com
Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
Re: KDE Applications Versioning
Hi, something like that? https://userbase.kde.org/KDE_Applications_Versioning Where to move it? And is the script in place now? Greetings Christoph - Ursprüngliche Mail - > On Wed, Jul 8, 2015 at 1:24 PM, Aleix Pol wrote: > > > On Wed, Jul 8, 2015 at 11:43 AM, Martin Klapetek > > wrote: > > > As the KDE Apps release is getting near, is this being > > considered/deployed? > > > Should we be setting some CMake variables? > > > > > > Cheers > > > -- > > > Martin Klapetek | KDE Developer > > > > Yes, that's why Albert was asking for a blog/wiki documentation. > > > > ...on a release-team mailing list to which I guess most of us are not > subscribed ;) > > Cheers > -- > Martin Klapetek | KDE Developer > -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
Re: KDE Applications Versioning
- Ursprüngliche Mail - > El Dissabte, 11 de juliol de 2015, a les 15:52:44, Christoph Cullmann va > escriure: > > Hi, something like that? > > > > https://userbase.kde.org/KDE_Applications_Versioning > > I'd like to make it clearer that this is optional and maybe also an example > that only uses KDE_APPLICATIONS_VERSION_MICRO > > Also KDE_APPLICATIONS_VERSION is not replaced at all, just MAJOR MINOR and > MICRO as in the script i linked. Yeah, thats true, I just wanted to show the typical boiler plate you might want. > > > Where to move it? > > userbase doesn't seem the right place for this tbh, what does it have to do > with users, techbase? Lol, ok, that's true, I actually wanted to add it to techbase, but guess after the login I ended up on the wrong wiki and did not check that again :/ > > > > And is the script in place now? > > I linked it in the email to the release-team thread (why so much list > hopping?), so yes. Because I am not on release-team :P I only read the request for some article here ;=) Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
Re: KDE Applications Versioning
- Ursprüngliche Mail - > El Dissabte, 11 de juliol de 2015, a les 16:59:13, Christoph Cullmann va > escriure: > > - Ursprüngliche Mail - > > > > > El Dissabte, 11 de juliol de 2015, a les 15:52:44, Christoph Cullmann va > > > > > > escriure: > > > > Hi, something like that? > > > > > > > > https://userbase.kde.org/KDE_Applications_Versioning > > > > > > I'd like to make it clearer that this is optional and maybe also an > > > example > > > that only uses KDE_APPLICATIONS_VERSION_MICRO > > > > > > Also KDE_APPLICATIONS_VERSION is not replaced at all, just MAJOR MINOR > > > and > > > MICRO as in the script i linked. > > > > Yeah, thats true, I just wanted to show the typical boiler plate you might > > want. > > > > Where to move it? > > > > > > userbase doesn't seem the right place for this tbh, what does it have to > > > do > > > with users, techbase? > > > > Lol, ok, that's true, I actually wanted to add it to techbase, but guess > > after the login I ended up on the wrong wiki and did not check that again > > :/ > > > > > > And is the script in place now? > > > > > > I linked it in the email to the release-team thread (why so much list > > > hopping?), so yes. > > > > Because I am not on release-team :P I only read the request for some > > article > > here ;=) > > Next time you send emails there, you may awnt to add a P.S: saying you're not > subscribed so people CC you on answers. Yeah, that was my fault, sorry ;=) I updated the page a bit: https://userbase.kde.org/KDE_Applications_Versioning If I get any feedback, until now, nobody touched the page, that this is OK, we should move it over to techbase, any idea for a good location there? Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
Re: KDE Applications Versioning
Hi, > Since this hasn't been finalized I didn't include it in my email to kde-cvs- > announce about the creation of the 15.08 branches for the KDE Applications > modules. > > Cheers, > Albert > > El Dimarts, 14 de juliol de 2015, a les 07:08:57, Andreas Cord-Landwehr va > escriure: > > On Monday 13 July 2015 23:14:17 Albert Astals Cid wrote: > > > I did a few tweaks, i still feel it seems this is "the official way" > > > other > > > than an "optional way" of defining the version but maybe that's just me. > > > > Hi, I have the same feeling as Albert that the current text is not clear > > enough that both variants (increase version by hand and using the scripted > > approach) are fine. > > > > What about adding an introduction paragraph like the following: > > > > - - > > Every application has an application version number that regular has to be > > increased to distinguish different versions of the application (e.g., > > features, bugfixes). When an application does not have its own release > > schedule but is released alongside with KDE Applications, there is also the > > version number of the KDE Applications release. It is the maintainer's duty > > to take care on increasing the version number regularly and there are > > specifically two possible ways: > > > > 1. increase the version number by hand for each new release > > 2. use the same version number as KDE Applications and let the release > > script update the version number > > > > In the following, we explain how to use the scripted version numbers. > > - - > > > > If it is OK this way, I can add it later today to the wiki page. I somehow missed that mail ;=) I am all for adding that paragraph and then moving the wiki page to the right place. Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
Re: KDE Applications Versioning
Hi, blog done, hope is ok that way, it should be clear enough that this is optional, I hope. http://kate-editor.org/2015/07/26/kde-applications-versioning/ I guess I will take a look in the next days and patch some applications for which the version got never touched since their KF5 port. Greetings Christoph - Ursprüngliche Mail - > El Dilluns, 20 de juliol de 2015, a les 09:42:40, Andreas Cord-Landwehr va > escriure: > > On Tuesday 14 July 2015 07:08:57 Andreas Cord-Landwehr wrote: > > > If it is OK this way, I can add it later today to the wiki page. > > > > Hi, since I did not hear any oppositions, I just added the paragraph to the > > wiki page draft. > > Ok, i moved it to https://community.kde.org/Applications/Versioning and > removed the construction notice. > > Cheers, > Albert > > > > > Cheers, > > Andreas > > -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
RFC: KDE Bugzilla Bugs Expiration
Hi, I think one of the problems with our current Bugzilla database is that it contains a lot of "old" bugs and wishs. As the manpower is limited and we sometimes not even keep up with the incoming new bugs, might it be a good idea to adopt a similar strategy like the Qt Project and expire bugs that got not changed since more than one year? The idea would that a scripts closes all bugs that have no activity in the last year e.g. on a weekly basis and the closing comment would contain some gentle note that if the bug is still an issue, the reporter (or any person on CC) can just reopen it again. I think this would make a lot of time consuming bug triaging much easier. Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
Re: [Development] Please help me get my pending review count down
Hi, is one of the problems the misuse of QDBus in KUniqueApplication before the actual QApplication is constructed? Would it be possible to just create in that case a temporary QCoreApplication on the stack in KUniqueApplication::start? Kate had similar "I get stuck" problems until the QApplication was correctly constructed in all cases before the first QDBus use. Greetings Christoph - Ursprüngliche Mail - > On Wednesday, July 29, 2015 11:03:15 AM Martin Klapetek wrote: > > On Wed, Jul 29, 2015 at 11:47 AM, Marc Mutz wrote: > > > On Wednesday 29 July 2015 09:04:42 Martin Klapetek wrote: > > > > Can you perhaps create a single diff against 5.5/dev/master > > > > which could be easily applied? That should make things > > > > much easier to help :) > > > > > > Assuming you're talking about the dbus changes, wouldn't you actually > > > want > > > to > > > cherry-pick them one by one and see which one breaks? > > > > Perhaps that should be done as well, yes, although Thiago requested the > > /whole set of changes/ to be tested: > > > > I need someone to take the whole set of changes, apply to their Qt 5.5 > > build > > > and test KF5-powered applications to see what gets broken and why. Please > > > provide patches to either QtDBus, KF5 or the applications. > > > > Which would be much simpler with a single diff. > > Gerrit gives you a git command to copy'n'paste and you can pull the changeset > and test it. That's much better than manually applying some plaintext diff. > > Bye > -- > Milian Wolff | milian.wo...@kdab.com | Software Engineer > KDAB (Deutschland) GmbH&Co KG, a KDAB Group company > Tel: +49-30-521325470 > KDAB - The Qt Experts -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
Re: Bringing back rsibreak from unmaintained
On Monday 17 August 2015 20:04:04 Albert Astals Cid wrote: > Hi guys, i just merged the frameworks port of rsibreak to master. > > rsibreak is in the unmaintained silo, i'd like to bring it back to > extragear- utils (i guess kdeutils is too much for this niche > app?). > > Anyone wants to review it? > > Other comments? -- Build files have been written to: /local/build/kf5/rsibreak /local/git/extragear/utils/rsibreak/src/rsitimer.cpp:26:20: fatal error: kdebug.h: No such file or directory #include ^ compilation terminated. make[2]: *** [src/CMakeFiles/rsibreak.dir/rsitimer.cpp.o] Error 1 /local/git/extragear/utils/rsibreak/src/rsiglobals.cpp:24:29: fatal error: kglobalsettings.h: No such file or directory #include ^ compilation terminated. make[2]: *** [src/CMakeFiles/rsibreak.dir/rsiglobals.cpp.o] Error 1 make[2]: Target `src/CMakeFiles/rsibreak.dir/build' not remade because of errors. make[1]: *** [src/CMakeFiles/rsibreak.dir/all] Error 2 make[1]: Target `all' not remade because of errors. make: *** [all] Error 2 make: Target `default_target' not remade because of errors. -- Failed: rsibreak
Re: Moving KDE Connect out of playground
On Tuesday 15 September 2015 02:13:17 Aleix Pol wrote: > Regarding the documentation, we discussed it briefly during the > sprint and we have the feeling that the documentation for such a > project would look more like a simple placeholder or something > easily outdated than anything. Furthermore, since there isn't a > clear main window of the application, it would be unintuitive to > get there. We're convinced nobody would ever end up there. The question is, does any icon of kde-connect appear in the K menu? If yes, people might want to open KHelpCenter to look for documentation. The check on the porting status page looks for an application .desktop file (assuming it appears in the K menu), that's why it flags missing documentation. Christoph
QIcon Search Paths Question
Hi,
I tried to set the icon search path relative to the application directory, e.g.
like:
QIcon::setThemeName(QStringLiteral("breeze"));
QIcon::setThemeSearchPaths(QStringList() <<
QCoreApplication::applicationDirPath() + QStringLiteral("/../Resources/icons"));
with breeze dir inside the "icons" path with the index.theme inside.
Sometimes, that even works, sometimes, not.
Is there anything special to do? Does KIconThemes play around with that, too?
Greetings
Christoph
--
----- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com
Science Park 1 Tel: +49-681-38360-22
66123 Saarbrücken Fax: +49-681-38360-20
GERMANYWWW: http://www.AbsInt.com
Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
Re: QIcon Search Paths Question
;=)
Forget my question, macdeployqt just purged my svg icon engine ;)
Greetings
Christoph
- Am 21. Okt 2015 um 20:00 schrieb cullmann cullm...@absint.com:
> Hi,
>
> I tried to set the icon search path relative to the application directory,
> e.g.
> like:
>
> QIcon::setThemeName(QStringLiteral("breeze"));
> QIcon::setThemeSearchPaths(QStringList() <<
> QCoreApplication::applicationDirPath() +
> QStringLiteral("/../Resources/icons"));
>
> with breeze dir inside the "icons" path with the index.theme inside.
>
> Sometimes, that even works, sometimes, not.
>
> Is there anything special to do? Does KIconThemes play around with that, too?
>
> Greetings
> Christoph
>
> --
> - Dr.-Ing. Christoph Cullmann -
> AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com
> Science Park 1 Tel: +49-681-38360-22
> 66123 Saarbrücken Fax: +49-681-38360-20
> GERMANYWWW: http://www.AbsInt.com
>
> Geschäftsführung: Dr.-Ing. Christian Ferdinand
> Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
--
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com
Science Park 1 Tel: +49-681-38360-22
66123 Saarbrücken Fax: +49-681-38360-20
GERMANYWWW: http://www.AbsInt.com
Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
Re: Review Request 125816: Allow building KF5::ProcessUi without QtWebkit
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125816/#review87517 --- One script is used to show detailed memory information (which I find rather useful). We could use QtWebEngine when QtWebKit is not available. - Christoph Feck On Oct. 27, 2015, 12:20 p.m., Alex Richardson wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125816/ > --- > > (Updated Oct. 27, 2015, 12:20 p.m.) > > > Review request for KDE Base Apps. > > > Repository: libksysguard > > > Description > --- > > The scripting feature will not be available but everything else will still > work. > > If we completely skip building processui plasma-workspace will fail halfway > through the build (not a CMake time!) because -lKF5::ProcessUi cannot be > found. > > > Diffs > - > > CMakeLists.txt 14d32d9453dd5e8bd71af9051585db245791d691 > config-ksysguard.h.cmake d95e1f570d835da92f5fa7e2835608fb85c9e9eb > processui/CMakeLists.txt 7f87b85e0201e63d69070a71203bbb34851a79c6 > processui/scripting.cpp efed8ff66f5442f4d86a1a964977e856b632ff52 > > Diff: https://git.reviewboard.kde.org/r/125816/diff/ > > > Testing > --- > > > Thanks, > > Alex Richardson > >
Re: Review Request 125816: Allow building KF5::ProcessUi without QtWebkit
> On Oct. 27, 2015, 1:19 p.m., Christoph Feck wrote: > > One script is used to show detailed memory information (which I find rather > > useful). We could use QtWebEngine when QtWebKit is not available. ... or QTextBrowser - Christoph --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125816/#review87517 --- On Oct. 27, 2015, 12:20 p.m., Alex Richardson wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125816/ > --- > > (Updated Oct. 27, 2015, 12:20 p.m.) > > > Review request for KDE Base Apps. > > > Repository: libksysguard > > > Description > --- > > The scripting feature will not be available but everything else will still > work. > > If we completely skip building processui plasma-workspace will fail halfway > through the build (not a CMake time!) because -lKF5::ProcessUi cannot be > found. > > > Diffs > - > > CMakeLists.txt 14d32d9453dd5e8bd71af9051585db245791d691 > config-ksysguard.h.cmake d95e1f570d835da92f5fa7e2835608fb85c9e9eb > processui/CMakeLists.txt 7f87b85e0201e63d69070a71203bbb34851a79c6 > processui/scripting.cpp efed8ff66f5442f4d86a1a964977e856b632ff52 > > Diff: https://git.reviewboard.kde.org/r/125816/diff/ > > > Testing > --- > > > Thanks, > > Alex Richardson > >
Re: Review Request 125910: Fix for Bug 334525 - Gwenview hangs when switching from normal to full screen mode
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125910/#review87800 --- kdeui/notifications/knotificationrestrictions.cpp (line 67) <https://git.reviewboard.kde.org/r/125910/#comment60248> I am not sure all compilers support initialization of (non-static) members inside the class declaration. I suggest to move it to the constructor. The same code is also present in knotification-framework. - Christoph Feck On Nov. 1, 2015, 2:15 p.m., Johannes Stefan wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125910/ > --- > > (Updated Nov. 1, 2015, 2:15 p.m.) > > > Review request for kdelibs and Martin Klapetek. > > > Bugs: 334525 > http://bugs.kde.org/show_bug.cgi?id=334525 > > > Repository: kdelibs > > > Description > --- > > Setting default reason for going into fullscreen mode > > > Diffs > - > > kdeui/notifications/knotificationrestrictions.cpp 818edea > > Diff: https://git.reviewboard.kde.org/r/125910/diff/ > > > Testing > --- > > Compiled an tested - DBus Log as expected: > > # begin DBUS-log # > method call sender=:1.223 -> dest=org.freedesktop.ScreenSaver serial=56 > path=/ScreenSaver; interface=org.freedesktop.ScreenSaver; member=Inhibit >string "Gwenview" >string "no_reason_specified" > method call sender=:1.6 -> dest=:1.3 serial=588 > path=/org/gnome/SessionManager; interface=org.gnome.SessionManager; > member=Inhibit >string "Gwenview" >uint32 0 >string "no_reason_specified" >uint32 8 > signal sender=:1.3 -> dest=(null destination) serial=351 > path=/org/gnome/SessionManager; interface=org.freedesktop.DBus.Properties; > member=PropertiesChanged >string "org.gnome.SessionManager" >array [ > dict entry( > string "InhibitedActions" > variant uint32 8 > ) >] >array [ >] > signal sender=:1.3 -> dest=(null destination) serial=352 > path=/org/gnome/SessionManager; interface=org.gnome.SessionManager; > member=InhibitorAdded >object path "/org/gnome/SessionManager/Inhibitor29" > method return sender=:1.3 -> dest=:1.6 reply_serial=588 >uint32 1169992534 > method call sender=:1.4 -> dest=:1.21 serial=56 > path=/org/gnome/Mutter/IdleMonitor/Core; > interface=org.gnome.Mutter.IdleMonitor; member=RemoveWatch >uint32 35 > method call sender=:1.6 -> dest=org.freedesktop.DBus serial=589 > path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch >string > "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',path='/org/freedesktop/DBus',arg0=':1.223'" > method call sender=:1.6 -> dest=org.freedesktop.DBus serial=590 > path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; > member=GetNameOwner >string ":1.223" > method return sender=:1.6 -> dest=:1.223 reply_serial=56 >uint32 1169992534 > method call sender=:1.6 -> dest=:1.21 serial=592 > path=/org/gnome/Mutter/DisplayConfig; > interface=org.freedesktop.DBus.Properties; member=Set >string "org.gnome.Mutter.DisplayConfig" >string "PowerSaveMode" >variant int32 0 > method call sender=:1.21 -> dest=:1.3 serial=1073 > path=/org/gnome/SessionManager; interface=org.gnome.SessionManager; > member=IsInhibited >uint32 16 > method call sender=:1.21 -> dest=org.freedesktop.DBus serial=1074 > path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=RemoveMatch >string > "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',path='/org/freedesktop/DBus',arg0=':1.4'" > method return sender=:1.21 -> dest=:1.4 reply_serial=56 > method return sender=:1.3 -> dest=:1.21 reply_serial=1073 >boolean false > # end of DBUS-log # > > > Thanks, > > Johannes Stefan > >
Re: Policy regarding QtWebKit and QtScript
Hi, >> Isn't the designated successor for QtScript QJSEngine >> (I even assumed there should be some porting tools?) > > That's what I meant under 'qml engines'. :) > > A relevant mail by Frederik: > http://lists.qt-project.org/pipermail/interest/2015-June/017446.html for KTextEditor: 1) kross is useless for it 2) QJSEngine: I tried to port with Qt 5.4, but it didn't allow for all things needed like setting up some global functions in the engine and wrapping custom datatypes like QtScript did, perhaps this has changed but as IMHO no porting guidelines exist, have not tried it again. (attached the state of the port, if somebody wants to give it a try) But as the above mail indicates, such a guide should come up. Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 qjs.diff.gz Description: GNU Zip compressed data
Re: Qt5 version of qimageblitz
On Wednesday 09 March 2016 08:08:14 Boudewijn Rempt wrote: > On Wed, 9 Mar 2016, Albert Astals Cid wrote: > > I guess for that we need to decide if it should be a framework > > first or not. > > Isn't kolourpaint the only user of qimageblitz at the moment? Krita > used to use it, years and years ago, but that's no longer the > case. If Kolourpaint is the only user, I'd actually suggest just > taking the code into kolourpaint and dropping the library > entirely. At least the KF5 port of tellico also uses it.
Re: Product versions on bugs.kde.org
On Saturday 12 March 2016 04:02:11 Alexander Potashev wrote: > I felt free and did the following: > > [...] > 7. Created product frameworks-baloo and added > versions 5.13.0+ [4]. Bugs for older, out-of-KF5 versions go into > the "Baloo" product. > > 8. Added product "BalooWidgets", it's part of KDE Applications. > Moved relevant bugs from the "Baloo" product. > 9. Added product "Baloo KCM", it's part of Plasma > (plasma-desktop.git/kcms/baloo). Moved relevant bugs from the > "Baloo" product. > > I guess now the products "kpeople" and "Baloo" can be obsoleted in > Bugzilla. > > > If the above looks good, please add the product "Baloo KCM" into > releaseme.git/plasma/plasma-add-bugzilla-versions. > > > [1] https://www.kde.org/announcements/kde-frameworks-5.6.0.php > [2] https://www.kde.org/announcements/kde-frameworks-5.8.0.php > [3] https://www.kde.org/announcements/kde-frameworks-5.9.0.php > [4] https://www.kde.org/announcements/kde-frameworks-5.13.0.php Thanks Alexander for cleaning this up. Could please also adjust the mappings data file for DrKonqi, so that crashes (e.g. in Baloo components) are reported against the right bugzilla product)? Thanks, Christoph Feck KDE Quality Team
Re: Cervisia?
On Saturday 04 June 2016 22:45:49 Martin Koller wrote: > On Friday 16 October 2015 06:53:19 Jeremy Whiting wrote: > > Awesome! Keep it up. Porting to Qt5/KF5 can happen on a branch > > and be done a small bit at a time if you like. There are also > > some scripts in kdesdk/kde-dev-scripts/kf5 that can help with > > the trivial changes. Most are executed like find -iname *.cpp | > > xargs scriptname, but if not they will say in a comment at the > > top of the script how to execute them. > > > > On Thu, Oct 15, 2015 at 8:02 PM, Martin Koller wrote: > > > On Thursday 15 October 2015 15:49:32 Jeremy Whiting wrote: > > >> Michael, Martin, > > >> > > >> Any progress on the cervisia front? Is there anything I can do > > >> to help? > > > > > > yes, a lot of progress! > > > We have already ported away from Qt3/KDE3 support classes. > > > This is already in master and I'm testing it by using it on a > > > daily basis. > > > > > > The next step would now be to start the port to KF5 - this has > > > not been started yet. > > Just for your information: I have now completed the KF5 port and > master now holds this version Thanks for the porting efforts, Martin! I tried compiling master branch, but get errors about many missing headers, such as klocale.h, kglobalsettings.h, kdemacros.h, kinputdialog.h, kiconloader.h, kdeversion.h, and kstatusbar.h For not yet completed ports, you need to add KF5::KDELibs4Support dependency. -- Christoph Feck KDE Quality Team
Re: kolourpaint now KF5 based
On Wednesday 13 July 2016 20:12:46 Martin Koller wrote: > just wanted to let you know that I have now completed the > kolourpaint port to KF5 and this is now in its master branch. I > have also updated kde-build-metadata Hope I did all correct. The about dialog says it is version 5.25.0 (=frameworks version). I guess this is not intended.
kcharselect maintainership
Hi, as agreed with previous maintainer Daniel Laidig, I am taking over maintainership for kcharselect. This includes the kcharselect application (from former kdeutlils package), as well as the kcharselect class in kwidgetsaddons framework. The default assignee in bugs.kde.org is already changed; if there is other stuff that needs to be updated, please notify me. Thanks, Christoph -- Christoph Feck KDE Quality Team https://kdepepo.wordpress.com
Re: Review Request 128684: Proofread + update khtml-general kcm docbook
> On Aug. 16, 2016, 9:05 a.m., David Faure wrote: > > doc/kcontrol/khtml-general/index.docbook, line 51 > > <https://git.reviewboard.kde.org/r/128684/diff/1/?file=474210#file474210line51> > > > > Well, qt5-webkit and kwebkitpart do still exist. They're just not > > really maintained (but then again that is a problem for konqueror itself as > > well, especially due to being built on top of deprecated web engines...). > > (I hate this situation.) > > Burkhard Lück wrote: > Thanks to your hints I just detected that kwebkitpart has a frameworks > branch. Building this branch I get the webkit engine back in konqueror kf5. > But kwebkitpart frameworks branch is unreleased, stable/released branch > is 1.3 kde4 based, master as well. > So should I update the docbooks for konqueror with kwebkitpart/frameworks > branch? > > Burkhard Lück wrote: > > So should I update the docbooks for konqueror with > kwebkitpart/frameworks branch? > > kde-doc-english: please comment/answer my question > thanks > > Yuri Chornoivan wrote: > +1 > > Luigi Toscano wrote: > The kwerbkitpart is under construction, and there may be a qwebengine > part instead or in addition. I would leave that part commented with a > reminder to revisit it before the documentation freeze. > > Burkhard Lück wrote: > Let's do it the other way round, leave kwebkitpart for now and revisit > before documentation freeze. > That we we get the konqueror except the kwebkit related stuff immediately > up to date and have minimal changes for now. > > Burkhard Lück wrote: > in https://bugs.kde.org/show_bug.cgi?id=368705#c1 Christoph says: > > "Konqueror and the WebKit part will be released as Qt5 versions starting > with KDE Applications 16.12 release." > > so we should stick with the kwebkitpart for now Sorry, I was too fast. kwebkitpart is in extragear, so it will not be automatically released. - Christoph --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128684/#review98408 --- On Aug. 15, 2016, 1:40 p.m., Burkhard Lück wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/128684/ > --- > > (Updated Aug. 15, 2016, 1:40 p.m.) > > > Review request for Documentation, KDE Base Apps, Plasma, and David Faure. > > > Repository: plasma-desktop > > > Description > --- > > proofread + update > comment webkit > > code in kde-baseapps - docbook in plasma-desktop? > > > Diffs > - > > doc/kcontrol/khtml-general/index.docbook 1b9c80e > > Diff: https://git.reviewboard.kde.org/r/128684/diff/ > > > Testing > --- > > passes checkXML5 > > > Thanks, > > Burkhard Lück > >
Re: Dropping kdelibs4-based applications in KDE Applications 17.12
On 11.11.2016 16:45, Dominik Haumann wrote: On Thu, Nov 10, 2016 at 11:42 PM, Albert Astals Cid wrote: Hi, my proposal would be to make KDE Applications 17.08 the last release we accept applications based on kdelibs4, that means people have a year until KDE Applications 17.12 to port the applications from the list below to KF5. The ones that aren't ported we would just drop to unmaintained or if they have an active developer team that somehow doesn't want to move to KF5 they could move to "extreagear". Will we still release the KDE4 platform for not-yet-ported extragear applications (Amarok etc.) with 17.12? If we stop releasing it, then we should also move all unported applications to 'unmaintained'. Any developer willing to port can surrect it from there. I know lots of you would want to see this happen *now* but remember there's people using those apps so dropping them makes them no good. Comments? I think this is a very good idea and support this. However, the list you provided is possibly longer, for instance there are applications that are not part of this the Applications release. I *know* that this sounds like it's off-topic, but I don't think it is for the following reason: What do you think about having a Randa meeting (or similar) with focus on finishing ports to KF5? Would that make sense? If we had developers with free time for other projects, that time would be better spent on helping projects such as KDEPIM, rekonq, or Calligra. These are applications several of our users would switch to if they worked. I'm thinking of apps like Kile or similar that while already ported, still don't have a stable release. I'm pretty sure there are many more. As far as I know, Kile developer had to wait for the KF5 release of Okular. Such an initiative would also show that we don't simply drop old apps, instead, we would show that we care to bring along as many apps as we can. But we also need someone caring for bugreports/regressions after the port. We have some applications ported (e.g. KTorrent) where the original developer no longer has time for bug handling, and now the regressions pile up. Of course, this would only work if we find enough developers that join such an event. See above. -- Christoph Feck https://kdepepo.wordpress.com/ KDE Quality Team
Re: Kwave is in kdemultimedia now
On 11.11.2016 20:41, Thomas Eschenbacher wrote: as suggested by Ben, I hereby to inform you that today Kwave has been moved to kdemultimedia :) Thanks for your patience :) Did sysadmins also add an entry at reviewboard or phabricator for code reviews? If not, which would you prefer?
Re: Review Request 129423: keditbookmarks: add standard icons and shortcuts to Undo/Redo actions
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129423/#review100929 --- Ship it! Ship It! - Christoph Feck On Nov. 18, 2016, 10:33 a.m., Jonathan Marten wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/129423/ > --- > > (Updated Nov. 18, 2016, 10:33 a.m.) > > > Review request for KDE Base Apps. > > > Repository: keditbookmarks > > > Description > --- > > These actions are created by QUndoStack in order that it can manage the > action text. However, this means that they do not get the standard KDE > action icon or shortcuts set. This change sets those by reference to the > appropriate KStandardAction. > > > Diffs > - > > src/kbookmarkmodel/commandhistory.cpp 53a8931 > > Diff: https://git.reviewboard.kde.org/r/129423/diff/ > > > Testing > --- > > Built keditbookmarks (split repository master version) with this change, > observed correct appearance and operation of Undo/Redo actions. > > > Thanks, > > Jonathan Marten > >
Re: CI Requirements - Lessons Not Learnt?
How much work would it be to allow contributors to upload new versions to the CI? In openSUSE, for example, we have separate repos that contain new package versions that are not yet in standard distribution repositories, and so are able to build and deploy unstable versions for practically all packages.
Re: Review Request 129935: Fix build for GCC 7
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129935/#review102448 --- Ship it! Ship It! - Christoph Feck On Feb. 8, 2017, 10:04 a.m., Antonio Larrosa Jimenez wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/129935/ > --- > > (Updated Feb. 8, 2017, 10:04 a.m.) > > > Review request for kdelibs. > > > Repository: kdelibs > > > Description > --- > > This fixes building with GCC 7 which fails with > "ISO C++ forbids comparison between pointer and integer [-fpermissive]" > > > Diffs > - > > kdeui/windowmanagement/netwm.cpp 0c8b0a7d455f40327a03c685b7a7ff2beda901e0 > > Diff: https://git.reviewboard.kde.org/r/129935/diff/ > > > Testing > --- > > I checked that building with GCC 7 shows: > /usr/src/packages/BUILD/kdelibs-4.14.28/kdeui/windowmanagement/netwm.cpp: In > member function 'void NETWinInfo::update(const long unsigned int*)': > /usr/src/packages/BUILD/kdelibs-4.14.28/kdeui/windowmanagement/netwm.cpp:4371:48: > error: ISO C++ forbids comparison between pointer and integer [-fpermissive] > p->blockCompositing = (data_ret != None); > ^~~~ > > and the submitted commit fixes this. > > > Thanks, > > Antonio Larrosa Jimenez > >
Re: Ksysguard dev
On 19.06.2017 20:50, Alexandre Biche wrote: I want to add network I/O stats to ksysguard but I you closed kde-workspace's github repo and I don't find the plasma 5 github repo. Can you give me the way to start contributing please Our repositories are at https://cgit.kde.org/ KSysGuard is splitted between 'ksysguard' and 'libksysguard'. It does not have a maintainer, so if you use phabricator for patches, please add the Plasma group as reviewers.
Re: libqaccessibilityclient now in kdereview
On 25.07.2017 13:25, Jonathan Riddell wrote: libqaccessibilityclient is now in kdereview. The autotests need Qt5Test, but if the dependency is not installed, building fails silently. Either require Qt5Test, or make the tests optional if Qt5Test was not found. Issue found by Fabian from openSUSE.
Re: kbackup in kdereview
On 10.01.2018 20:03, Martin Koller wrote: On Mittwoch, 10. Jänner 2018 00:05:53 CET Albert Astals Cid wrote: * You should remove the kol...@aon.at in the about data and get a bugs.kde.org product How can I get one ? Either via sysadmin ticket https://community.kde.org/Sysadmin or via bugzilla, product "bugs.kde.org", component "product/component changes". We need a list of components (or just "general") including description and default assignee, and an initial list of versions (or just "unspecified"). While you are at it, the same for liquidshell, please; I have some bug reports lying around 8) -- Christoph Feck
Re: Upcoming reorganisation of the CI system
On 14.08.2018 15:03, Ben Cooksley wrote: Currently CI jobs are all created within a flat namespace, meaning that it is quite difficult to view the overall status of an individual project. Additionally, it creates the issue that the main default view can take a significant amount of time to load. To resolve this we intend to shift everything within Folders in Jenkins. These folders will be structured in the form of Product / Project / Will we still be able to see the status of all Applications (or all Frameworks) without clicking hundreds of subfolders? This is useful to get an overview before doing releases. Christoph Feck
Re: CI System Reorganisation
On 09.09.2018 10:59, Ben Cooksley wrote: As a followup to my earlier mail sent about 3 weeks ago, i've now transitioned all builds on the CI system over to the folder layout previously described. Builds can now be found in folders following the following structure on Jenkins: / How I can view all of "stable" Applications on a single page? I remember I asked if it would still be possible after the change, but I cannot see a filter or link to get an overview of all builds. Christoph Feck
Re: KDE release
On 02/18/19 15:00, Michael Reeves wrote: I'm looking to tag for 1.8 at the end of the week. If more time is needed More time for what? Do you plan to include KDiff in the KDE Applications 19.04 bundle? let me know. Binary files are ignored during diff generation due tomorrow assumptions in the under laying code the require a text file. The plan is allow simple is equal comparison with but binaries. However the current comparison code does not respond well to such files. ENOPARSE Christoph Feck
Possible to move some KF5 frameworks to invent?
Hi, is it possible to move individual framework modules over to invent.kde.org or will that be done at once somewhen in the future? Would be interested to move syntax-highlighting and ktexteditor if that is possible. But if that shall be done as bulk in the future I can wait ;=) Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: Possible to move some KF5 frameworks to invent?
On 2019-08-11 16:53, Albert Astals Cid wrote: El diumenge, 11 d’agost de 2019, a les 12:33:19 CEST, Christoph Cullmann va escriure: Hi, is it possible to move individual framework modules over to invent.kde.org or will that be done at once somewhen in the future? Seems kde-frameworks-devel would be a better list to ask about this. You are right ;=) Would be interested to move syntax-highlighting and ktexteditor if that is possible. But if that shall be done as bulk in the future I can wait ;=) I personally feel the loss of "email gets sent to kde-frameworks-devel on MR" is a problem. Hmm, shouldn't we be able to fix that with adding some "kde-frameworks-devel" user to our gitlab instance that configures it's notification mail address for the KDE group to kde-frameworks-devel@? Also i remember dfaure not being very thrilled about the "not possible to force push to 'my branches' on the main repo" issue. Therefore I CC'ed David, as he needs to be ok with this anyways doing the whole release work. Greetings Christoph Cheers, Albert Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: Possible to move some KF5 frameworks to invent?
Hi, > Unfortunately the problem isn't with Frameworks, Applications and > Plasma - they're easy to handle and their naming can be scripted > without too much trouble. > The problem lies with Extragear, which has a large number of projects, > all of which have different rules for what a stable branch is named. As Albert said, the solution would be to establish a common scheme for protected branches. Actually my suggestion was a common scheme for unprotected branches. perhaps this would be some good BoF at Akademy: What is needed to move frameworks development to invent.kde.org. (I assume we want to do that some when in the future anyways) Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: Possible to move some KF5 frameworks to invent?
Hi, perhaps this would be some good BoF at Akademy: What is needed to move frameworks development to invent.kde.org. (I assume we want to do that some when in the future anyways) At this point my planning expected that Frameworks would move when the rest of KDE moves (which will likely be a massive migration that happens in very quick succession once everything is ready). is there some timeline known when this might happen? And is there some help needed to handle the transition? Btw., thanks already for all the work you and others did on improving our infrastructure! Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: KDE Frameworks 5.62.0 released
On 09/14/19 13:35, David Faure wrote: 14th September 2019. KDE today announces the release of KDE Frameworks 5.62.0. http://kde.org/announcements/kde-frameworks-5.62.0.php This web page says the release number is 5.1.0.
HiDPI issues with KDE applications
Hi, I just checked again the HIDPI support of Kate/KWrite on Windows and it "sucked". It seems we never properly did setup the stuff to auto-scale, e.g. the QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling, true); call was missing, we only had the QCoreApplication::setAttribute(Qt::AA_UseHighDpiPixmaps, true); part that we sprinkled in most of KDE's things in the past. I now rectified that for Kate/KWrite, shall we do this for all our applications? Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: HiDPI issues with KDE applications
On 2019-09-28 17:34, Albert Vaca Cintora wrote: If this has to be done for all apps, why isn't it done at Qt level? Because in some cases, that breaks the application, e.g. if it expects pixel to be real physical pixel 1:1. Therefore, after changing that, one needs to try the application if it behaves OK. (I did that for KWrite/Kate) Greetings Christoph On Sat, Sep 28, 2019 at 5:05 PM Christoph Cullmann wrote: Hi, I just checked again the HIDPI support of Kate/KWrite on Windows and it "sucked". It seems we never properly did setup the stuff to auto-scale, e.g. the QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling, true); call was missing, we only had the QCoreApplication::setAttribute(Qt::AA_UseHighDpiPixmaps, true); part that we sprinkled in most of KDE's things in the past. I now rectified that for Kate/KWrite, shall we do this for all our applications? Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: HiDPI issues with KDE applications
On 2019-09-28 17:37, Christoph Cullmann wrote: On 2019-09-28 17:34, Albert Vaca Cintora wrote: If this has to be done for all apps, why isn't it done at Qt level? Because in some cases, that breaks the application, e.g. if it expects pixel to be real physical pixel 1:1. Therefore, after changing that, one needs to try the application if it behaves OK. (I did that for KWrite/Kate) Still not properly scaled seem to be things that get painted via QStyle, like the KMultiTabBar buttons: QStyleOptionButton opt; opt.initFrom(this); opt.icon = icon(); opt.iconSize = iconSize(); // removes the QStyleOptionButton::HasMenu ButtonFeature opt.features = QStyleOptionButton::Flat; QPainter painter(this); style()->drawControl(QStyle::CE_PushButton, &opt, &painter, this); => here I still see artifacts, both on Linux and Windows (easy to try with some export QT_SCALE_FACTOR=3) Greetings Christoph On Sat, Sep 28, 2019 at 5:05 PM Christoph Cullmann wrote: Hi, I just checked again the HIDPI support of Kate/KWrite on Windows and it "sucked". It seems we never properly did setup the stuff to auto-scale, e.g. the QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling, true); call was missing, we only had the QCoreApplication::setAttribute(Qt::AA_UseHighDpiPixmaps, true); part that we sprinkled in most of KDE's things in the past. I now rectified that for Kate/KWrite, shall we do this for all our applications? Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: HiDPI issues with KDE applications
On 2019-09-28 18:23, Michael Reeves wrote: While were on this topic https://bugreports.qt.io/browse/QTBUG-75039 It seems qt has a few bugs related to this. Make sure multi monitor setups are tested as well. I have no multi-monitor different DPI setup available. But if somebody has, for sure, testing there would be appreciated. I can only tell, that without the below change, already on one screen it looks horrible :=) Greetings Christoph On Sat, Sep 28, 2019, 11:05 AM Christoph Cullmann wrote: Hi, I just checked again the HIDPI support of Kate/KWrite on Windows and it "sucked". It seems we never properly did setup the stuff to auto-scale, e.g. the QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling, true); call was missing, we only had the QCoreApplication::setAttribute(Qt::AA_UseHighDpiPixmaps, true); part that we sprinkled in most of KDE's things in the past. I now rectified that for Kate/KWrite, shall we do this for all our applications? Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: Keysmith in kdereview
On 12/28/19 19:17, Jesus Varela wrote: I am new and have tons of questions about all these emails I see. From what I understand there is software being added to the core KDE framework. Will this make the framework less desired due to it being bloated with tons of features? Or is it desired to have more features even if it makes the framework heavier? I hear about a KDE/QT powered phone in the works but then I wonder how a huge framework like KDE will work on a mobile device. Is there a way to break the framework into parts that only deploy the necessary pieces? Sorry for the noob questions. Please refer me to any docs I should read. Our framework is already splitted into dozens of individual libraries, see https://techbase.kde.org/KDE_Frameworks -- Christoph Feck
Re: CMake config & target challenges on moving to KF5 namespace; dir structure & API dox (Re: Submitting Grantlee as a KF5 Framework)
Hi, With my KTextEditor hat on: KF6:TextDocument implies somehow a link to QTextDocument or KF6:TextEditor, which both is incorrect, right? QTextDocument is exactly what it's about, which makes the name KF6::TextDocument fully appropriate and correct. Before starting this work, let's clarify whether we can find a more unique name (like KF6:GrantleeTextDocument). The name I suggest is already correct. Since I haven't used Grantlee yet, I sm likely not the best person to find a better name ;) Remember, Grantlee is a set of Frameworks (*Just like KF5/6*) which happens to contain just TWO independent libraries. Hmm, I am not that sure about that naming. I see that it provides stuff with QTextDocument in mind, but KF6::TextDocument would in my eyes more look like some generic "enhanced" QTextDocument, but Grantlee provides a very specific extension. Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
KUserFeedback integration for Kate
Hi, I created some initial merge request for basic user feedback integration into Kate: https://invent.kde.org/kde/kate/merge_requests/60 To do this properly like described in https://community.kde.org/Policies/Telemetry_Policy I would like to have people review this change and raise issues that might violate our policy. For now, we just collect some usage statistics. Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
KUserFeedback integration for Kate
Hi, I created some initial merge request for basic user feedback integration into Kate: https://invent.kde.org/kde/kate/merge_requests/60 To do this properly like described in https://community.kde.org/Policies/Telemetry_Policy I would like to have people review this change and raise issues that might violate our policy. Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: Recommendation: drop ProvidersUrl entry to rely on default value
On 01/30/20 13:53, Friedrich W. H. Kossebau wrote: as found out by discussion on irc, a good solution for everyone relying on the default GHNS storage as provided by KDE is to just not hard-code any value for ProvidersUrl, but leave it out and let KNewStuff default to what is built into the KNewStuff library as current value. Does it work with all KNewStuff 5.x versions? Otherwise, the required KF5 version would need to be bumped where this change was made. -- Christoph Feck
KUserFeedback integration for Kate
Hi, I created some initial merge request for basic user feedback integration into Kate: https://invent.kde.org/kde/kate/merge_requests/60 To do this properly like described in https://community.kde.org/Policies/Telemetry_Policy I would like to have people review this change and raise issues that might violate our policy. For now, we just collect some usage statistics. Please provide your feedback either on this list or on the merge request. Thanks! Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: KUserFeedback integration for Kate
On 2020-02-02 12:27, Christoph Cullmann wrote: Hi, I created some initial merge request for basic user feedback integration into Kate: https://invent.kde.org/kde/kate/merge_requests/60 To do this properly like described in https://community.kde.org/Policies/Telemetry_Policy I would like to have people review this change and raise issues that might violate our policy. For now, we just collect some usage statistics. Please provide your feedback either on this list or on the merge request. I got two positive reviews for this. I merged this now, to be used in 20.04. I added the relevant info to https://community.kde.org/Telemetry_Use If something is still bad/missing/..., please ping us on kwrite-de...@kde.org or open some issue for that! Thanks! Greetings Christoph Thanks! Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: Review Kid3
On 02/13/20 07:11, Urs Fleisch wrote: As you may know, Kid3, an audio tagger, has moved from SourceForge.net to kde.org. Jonathan Riddell is attending the incubation process as a sponsor. To complete the incubation, I would kindly ask you to execute a KDE review on the project. Website: https://kid3.kde.org/ Git, Issues: https://invent.kde.org/kde/kid3/ Is there a way to subscribe to bugs reported there? Incubator: https://community.kde.org/Incubator/Projects/kid3 Translation state: https://l10n.kde.org/stats/gui/trunk-kf5/po/kid3_qt.po/ Documentation state: https://l10n.kde.org/stats/doc/trunk-kf5/po/kid3.po/ Kid3 exists since 2003 and I would say that it is quite mature. As it is also available as a Qt-only version (without KDE dependencies) and for macOS, Windows and Android, the build system differs a bit from the typical KDE application. -- Christoph Feck KDE Bug Triaging Team
Re: Review Kid3
On 02/13/20 22:14, Albert Astals Cid wrote: You should change the bug reporting to use bugzilla not your email address in KAboutData Right. Urs, could you please request creation of a bugzilla product? Thanks, Christoph
Re: Is kdeinit still actual?
On 04/27/20 12:53, Alexander Volkov wrote: So, does it still makes sense to use kdeinit? https://phabricator.kde.org/T12140
Re: KF5 kwallet, kwalletd and wallet manager questions
On Saturday 24 August 2013 12:31:20 Valentin Rusu wrote: > Hello, > > Now that frameworks splitting is almost done ;-) with some people > even running KF5-based sessions on their systems, I'd like to plan > kwallet porting and integration. BTW, I'd like also to announce > that I agreed with Michael Leupold to take over the maintainership > [...] Nice to see you stepping up to the plate :) Could you please inform bugzilla maintainers to change the default assignee address for kwalletmanager and kdelibs/kwallet? Merci Christoph Feck (kdepepo) KDE Quality Team
Re: Review Request 112319: Fix network stats with new systemd interface names
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112319/ --- (Updated Sept. 3, 2013, 9:34 p.m.) Review request for kde-workspace, Solid and John Tapsell. Changes --- Add some reviewers. Description --- The parsing of network stats for interface names longer than 6 characters failed, because the parsing started at a fixed position. Attached patch fixes the issue. Additionally, it was suggest to skip the wireless status field by "parsing" it, instead of assuming it is always four digits. This addresses bug 315259. http://bugs.kde.org/show_bug.cgi?id=315259 Diffs - ksysguard/ksysguardd/Linux/netdev.c 2d82194 Diff: http://git.reviewboard.kde.org/r/112319/diff/ Testing --- Verified by two testers, see bug 315259. Thanks, Christoph Feck
Re: kde-workspace master becomes Qt5-based
On Tuesday 01 October 2013 15:25:27 Sebastian Kügler wrote: > On Tuesday, October 01, 2013 15:11:51 Stephen Kelly wrote: > > > We're planning to merge the frameworks-scratch branch of > > > kde-workspace into master next Monday. > > > > I tried building the branch. It requires qimageblitz, which I > > didn't see a Qt 5 version for, and soprano which has a > > non-building qt5_port branch. > > > > Do you have local working branches of those? > > They're optional. I don't need them to build. They have not been > ported yet. http://websvn.kde.org/trunk/kdesupport/qimageblitz/?view=log
Re: Review Request 112852: Proposed patch to enable compilation of nepomuk-core on Mac
> On Sept. 23, 2013, 4:18 p.m., Sune Vuorela wrote: > > Ship It! Nicolas, do you have or want to obtain commit rights? If not, Nepomuk developers can commit it for you. - Christoph --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112852/#review40588 --- On Sept. 21, 2013, 7:53 a.m., Nicolas Pavillon wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/112852/ > --- > > (Updated Sept. 21, 2013, 7:53 a.m.) > > > Review request for kdelibs and Nepomuk. > > > Bugs: https://bugs.kde.org/show_bug.cgi?id=325058 > > http://bugs.kde.org/show_bug.cgi?id=https://bugs.kde.org/show_bug.cgi?id=325058 > > > Repository: nepomuk-core > > > Description > --- > > Patch to solve the bug reported at > https://bugs.kde.org/show_bug.cgi?id=325058. > > > Diffs > - > > tools/nepomukctl/main.cpp 9d350ea > > Diff: http://git.reviewboard.kde.org/r/112852/diff/ > > > Testing > --- > > Applied the patch on several OS X platforms to ensure that compilation does > not crash. See https://trac.macports.org/ticket/40498 for details. > > > Thanks, > > Nicolas Pavillon > >
Re: Review Request 113185: Cursor Theme KCM: Show correct resize cursor in preview for themes without a file called "size_fdiag"
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113185/#review41483 --- Ship it! Ship It! - Christoph Feck On Oct. 10, 2013, 9:51 a.m., Wolfgang Bauer wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/113185/ > --- > > (Updated Oct. 10, 2013, 9:51 a.m.) > > > Review request for kde-workspace, kwin, Fredrik Höglund, and Thomas Lübking. > > > Bugs: 325837 > http://bugs.kde.org/show_bug.cgi?id=325837 > > > Repository: kde-workspace > > > Description > --- > > Apparently in XCursorTheme::findAlternative() (file > kcontrol/input/xcursor/xcursortheme.cpp) the alternatives for "size_bdiag" > and "size_fdiag" are swapped, so for themes not containing "size_fdiag" the > wrong resize cursor is shown in the preview. > > This patch fixes that long standing bug. (there has been no change to that > function since 2007!) > > This also fixes the glitch mentioned in bug#325763, that the wrong arrows are > used for the window resize hint after the theme change is applied (for the > current X session). > > > Diffs > - > > kcontrol/input/xcursor/xcursortheme.cpp 010c9ad > > Diff: http://git.reviewboard.kde.org/r/113185/diff/ > > > Testing > --- > > - Enter systemsettings->Workspace Appearance->Cursor Theme > - Select a theme without "size_fdiag", f.e.: crystalwhite, DMZ, Adwaita > - Look at the preview: without the patch, the wrong resize cursor is shown, > with the patch it's the same as for Oxygen e.g. > See atached screenshots > > > File Attachments > > > KCM without the patch > > http://git.reviewboard.kde.org/media/uploaded/files/2013/10/10/9cb9ae8c-6614-49ea-aae2-fdbeb36dd71e__cursor.png > KCM with the patch > > http://git.reviewboard.kde.org/media/uploaded/files/2013/10/10/f3cf8c6d-d2a0-4e96-8f77-75a53f66395f__cursor2.png > > > Thanks, > > Wolfgang Bauer > >
Re: Review Request 113219: Fix struct initialization which is invalid for C++11
> On Oct. 12, 2013, 6:23 p.m., Jiří Pinkava wrote: > > Ship It! Thanks Jiří. If possible, please request commit rights to the KDE repositories, so you can commit yourself after each review. This simplifies the work for others. - Christoph --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113219/#review41609 --- On Oct. 12, 2013, 3:10 p.m., Jiří Pinkava wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/113219/ > --- > > (Updated Oct. 12, 2013, 3:10 p.m.) > > > Review request for kdelibs. > > > Repository: kdelibs > > > Description > --- > > One more small step to C++11 support for kde > > > Diffs > - > > kjs/identifier.cpp 7126a88 > > Diff: http://git.reviewboard.kde.org/r/113219/diff/ > > > Testing > --- > > build > > > Thanks, > > Jiří Pinkava > >
Re: Review Request 113219: Fix struct initialization which is invalid for C++11
> On Oct. 12, 2013, 6:23 p.m., Jiří Pinkava wrote: > > Ship It! > > Christoph Feck wrote: > Thanks Ji?í. If possible, please request commit rights to the KDE > repositories, so you can commit yourself after each review. This simplifies > the work for others. reviewboard isn't even Unicode safe. In 2013 ASCII still rulez. - Christoph --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113219/#review41609 --- On Oct. 12, 2013, 3:10 p.m., Jiří Pinkava wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/113219/ > --- > > (Updated Oct. 12, 2013, 3:10 p.m.) > > > Review request for kdelibs. > > > Repository: kdelibs > > > Description > --- > > One more small step to C++11 support for kde > > > Diffs > - > > kjs/identifier.cpp 7126a88 > > Diff: http://git.reviewboard.kde.org/r/113219/diff/ > > > Testing > --- > > build > > > Thanks, > > Jiří Pinkava > >
Re: Review Request 113413: Improved Keyboard Layout Preview
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113413/#review42378 --- How does it look on 1024 pixel wide screens (not that I want to mention 800 pixels...) I hope the key size and font size is not hard coded, did not look at the code yet. - Christoph Feck On Oct. 25, 2013, 7:13 p.m., shivam makkar wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/113413/ > --- > > (Updated Oct. 25, 2013, 7:13 p.m.) > > > Review request for KDE Runtime, kde-workspace and Andriy Rysin. > > > Repository: kde-workspace > > > Description > --- > > Improved keyboard layout preview > added geometry feature, multi-level keys (>4) and parsed geometry file using > Boost c++ libraries and tool tip showing symbol names. > my GSoC-13 project ! > > > Diffs > - > > kcontrol/keyboard/CMakeLists.txt 973a39d > kcontrol/keyboard/CMakeLists.txt f92c96b > kcontrol/keyboard/CMakeLists.txt 59b366e > kcontrol/keyboard/CMakeLists.txt 2f0589c > kcontrol/keyboard/CMakeLists.txt d39d29e > kcontrol/keyboard/CMakeLists.txt ee02f2c > kcontrol/keyboard/CMakeLists.txt 6c51586 > kcontrol/keyboard/CMakeLists.txt c9a0ae3 > kcontrol/keyboard/CMakeLists.txt 3a2e729 > kcontrol/keyboard/CMakeLists.txt ad92fa3 > kcontrol/keyboard/CMakeLists.txt 973a39d > kcontrol/keyboard/kcm_add_layout_dialog.h 5273347 > kcontrol/keyboard/kcm_add_layout_dialog.h edf4336 > kcontrol/keyboard/kcm_add_layout_dialog.h 5273347 > kcontrol/keyboard/kcm_add_layout_dialog.cpp 444da8e > kcontrol/keyboard/kcm_add_layout_dialog.cpp b9d4ac2 > kcontrol/keyboard/kcm_add_layout_dialog.cpp 5a597a7 > kcontrol/keyboard/kcm_add_layout_dialog.cpp 29ca074 > kcontrol/keyboard/kcm_add_layout_dialog.cpp d893308 > kcontrol/keyboard/kcm_add_layout_dialog.cpp 84bac6e > kcontrol/keyboard/kcm_add_layout_dialog.cpp 444da8e > kcontrol/keyboard/kcm_keyboard.ui f64eeea > kcontrol/keyboard/kcm_keyboard_widget.h 58256df > kcontrol/keyboard/kcm_keyboard_widget.h 58256df > kcontrol/keyboard/kcm_keyboard_widget.cpp e513a41 > kcontrol/keyboard/kcm_keyboard_widget.cpp 9d3f010 > kcontrol/keyboard/kcm_keyboard_widget.cpp f71239a > kcontrol/keyboard/kcm_keyboard_widget.cpp 8922dc6 > kcontrol/keyboard/kcm_keyboard_widget.cpp ede5ce6 > kcontrol/keyboard/kcm_keyboard_widget.cpp 72f4b4b > kcontrol/keyboard/kcm_keyboard_widget.cpp c9a6910 > kcontrol/keyboard/preview/TODO 784924f > kcontrol/keyboard/preview/TODO 784924f > kcontrol/keyboard/preview/geometry_components.h PRE-CREATION > kcontrol/keyboard/preview/geometry_components.h 5723b01 > kcontrol/keyboard/preview/geometry_components.h e10837a > kcontrol/keyboard/preview/geometry_components.h 3381c10 > kcontrol/keyboard/preview/geometry_components.h a99432a > kcontrol/keyboard/preview/geometry_components.h d43368f > kcontrol/keyboard/preview/geometry_components.h dc1cdde > kcontrol/keyboard/preview/geometry_components.h 2a3347d > kcontrol/keyboard/preview/geometry_components.h e686302 > kcontrol/keyboard/preview/geometry_components.h d8e3ae8 > kcontrol/keyboard/preview/geometry_components.h e814476 > kcontrol/keyboard/preview/geometry_components.h PRE-CREATION > kcontrol/keyboard/preview/geometry_components.cpp PRE-CREATION > kcontrol/keyboard/preview/geometry_components.cpp 6c04078 > kcontrol/keyboard/preview/geometry_components.cpp c31cbf4 > kcontrol/keyboard/preview/geometry_components.cpp bdd8856 > kcontrol/keyboard/preview/geometry_components.cpp dd3844a > kcontrol/keyboard/preview/geometry_components.cpp e395e25 > kcontrol/keyboard/preview/geometry_components.cpp 35d7e31 > kcontrol/keyboard/preview/geometry_components.cpp 1d8b69e > kcontrol/keyboard/preview/geometry_components.cpp 219b57b > kcontrol/keyboard/preview/geometry_components.cpp 4ce3f87 > kcontrol/keyboard/preview/geometry_components.cpp 3ce015a > kcontrol/keyboard/preview/geometry_components.cpp PRE-CREATION > kcontrol/keyboard/preview/geometry_parser.h PRE-CREATION > kcontrol/keyboard/preview/geometry_parser.h 218b5ce > kcontrol/keyboard/preview/geometry_parser.h d7d964f > kcontrol/keyboard/preview/geometry_parser.h adf76dd > kcontrol/keyboard/preview/geometry_parser.h 42657ce > kcontrol/keyboard/preview/geometry_parser.h fcb5617 > kcontrol/keyboard/preview/geometry_parser.h 9beed17
Re: Review Request 113471: Fix crash when removing an item while we are adding one
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113471/#review42418 --- Ah, that makes sense, thanks for your investigation! What could be done to improve it, is to let the timer fire again sometimes later, until the item could actually be removed. I am not sure, though, if it is needed, in other words, what happens when items do not get removed by the timer. But since this seems to workaround the crash, it should get into 4.11.3. Someone else must approve. - Christoph Feck On Oct. 27, 2013, 10:36 a.m., Albert Astals Cid wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/113471/ > --- > > (Updated Oct. 27, 2013, 10:36 a.m.) > > > Review request for kde-workspace, Plasma, Àlex Fiestas, and Michael Zanetti. > > > Bugs: 311871 > http://bugs.kde.org/show_bug.cgi?id=311871 > > > Repository: kde-workspace > > > Description > --- > > Reading https://bugs.kde.org/show_bug.cgi?id=311871#c41 you can see that it > happens that we are doing a > #78 0x7f4eff8c5ffb in QDeclarativeListModel::insert (this=0x1ebbdb0, > index=0, valuemap=...) at util/qdeclarativelistmodel.cpp:436 > and then we end up reentring and doing > #16 0x7f4eff8c737f in QDeclarativeListModel::remove (this=0x1ebbdb0, > index=6) at util/qdeclarativelistmodel.cpp:402 > > Some of the stuff that depends on the QDeclarativeListModel doesn't seem to > like getting a "remove" while a "insert" is happening and to be honest m in > no mood to fix that, so basically I'm protecting against that happening in > our QML code. From what i read you have to be extremely unlucky since the > timer only triggers each 10 minutes and it has to trigger at the same time a > notification is being added, but oh well, the backtrace points to it and two > different people in two different systems say it has stopped the crashes so I > don't think it hurts to have this in. > > > Diffs > - > > > plasma/generic/applets/notifications/contents/ui/NotificationDelegate/NotificationDelegate.qml > bf33eb1 > plasma/generic/applets/notifications/contents/ui/Notifications.qml 114ead2 > > Diff: http://git.reviewboard.kde.org/r/113471/diff/ > > > Testing > --- > > I can't reproduce it in my desktop but Alex and Michael have been running > this patch for weeks and can certainly say that the crashing situation has > improved (i.e. no crashes in days with this patch and crashes daily without > it). > > > Thanks, > > Albert Astals Cid > >
Re: Review Request 113471: Fix crash when removing an item while we are adding one
> On Oct. 27, 2013, 11:05 a.m., Christoph Feck wrote: > > Ah, that makes sense, thanks for your investigation! > > > > What could be done to improve it, is to let the timer fire again sometimes > > later, until the item could actually be removed. I am not sure, though, if > > it is needed, in other words, what happens when items do not get removed by > > the timer. > > > > But since this seems to workaround the crash, it should get into 4.11.3. > > Someone else must approve. > > Albert Astals Cid wrote: > Well, the timer will trigger again 10 minutes later, and this is just for > "cleaning up" the list a bit, so at most you'll have a few more notifications > for a while, won't cause anything bad. The timer says "repeat: false", and if it is triggered again, probably on a different "index"? - Christoph --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113471/#review42418 --- On Oct. 27, 2013, 10:36 a.m., Albert Astals Cid wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/113471/ > --- > > (Updated Oct. 27, 2013, 10:36 a.m.) > > > Review request for kde-workspace, Plasma, Àlex Fiestas, and Michael Zanetti. > > > Bugs: 311871 > http://bugs.kde.org/show_bug.cgi?id=311871 > > > Repository: kde-workspace > > > Description > --- > > Reading https://bugs.kde.org/show_bug.cgi?id=311871#c41 you can see that it > happens that we are doing a > #78 0x7f4eff8c5ffb in QDeclarativeListModel::insert (this=0x1ebbdb0, > index=0, valuemap=...) at util/qdeclarativelistmodel.cpp:436 > and then we end up reentring and doing > #16 0x7f4eff8c737f in QDeclarativeListModel::remove (this=0x1ebbdb0, > index=6) at util/qdeclarativelistmodel.cpp:402 > > Some of the stuff that depends on the QDeclarativeListModel doesn't seem to > like getting a "remove" while a "insert" is happening and to be honest m in > no mood to fix that, so basically I'm protecting against that happening in > our QML code. From what i read you have to be extremely unlucky since the > timer only triggers each 10 minutes and it has to trigger at the same time a > notification is being added, but oh well, the backtrace points to it and two > different people in two different systems say it has stopped the crashes so I > don't think it hurts to have this in. > > > Diffs > - > > > plasma/generic/applets/notifications/contents/ui/NotificationDelegate/NotificationDelegate.qml > bf33eb1 > plasma/generic/applets/notifications/contents/ui/Notifications.qml 114ead2 > > Diff: http://git.reviewboard.kde.org/r/113471/diff/ > > > Testing > --- > > I can't reproduce it in my desktop but Alex and Michael have been running > this patch for weeks and can certainly say that the crashing situation has > improved (i.e. no crashes in days with this patch and crashes daily without > it). > > > Thanks, > > Albert Astals Cid > >
Re: Review Request 102231: Pass KAboutData::productName() to DrKonqi
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102231/ --- (Updated Oct. 27, 2013, 7 p.m.) Status -- This change has been discarded. Review request for KDE Runtime, kdelibs, Darío Andrés Rodríguez, and George Kiagiadakis. Repository: kdelibs Description --- Some applications, such as muon and Calligra apps, specify a bugzilla product/component via the KAboutData::setProductName() call. This works fine for bug reports via the "Report Bug..." menu, but fails for crashes. These currently go to "kde/general" when the product is not found. This patch adds a "--productname" parameter to the internal DrKonqi invokation call from the KDE default crash handler, and it is expected that DrKonqi developers decide if they add this feature in DrKonqi. It should handle both pure product names (such as "muon"), as well as product/component combinations (e.g. "muon/installer"). Diffs - kdecore/kernel/kaboutdata.h 16861f4 kdecore/kernel/kaboutdata.cpp e49bddb kdeui/util/kcrash.cpp b7abece Diff: http://git.reviewboard.kde.org/r/102231/diff/ Testing --- I forced a crash via Q_ASSERT in a test application, and the "--productname" parameter got added when it was specified via setProductName(). DrKonqi failed to handle it, though, it aborted with "drkonqi: Unknown option 'productname'." Thanks, Christoph Feck
Review Request 113504: Fix krunner calculator letter check
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113504/ --- Review request for kde-workspace and Plasma. Bugs: 326059 http://bugs.kde.org/show_bug.cgi?id=326059 Repository: kde-workspace Description --- The calculator runner now supports the syntax without the '=', so you can simply type in '3+5' and have the result. An additional commit added a letter check, so that it will not try to compute with normal text input, but this broke any calculations with any functions, such as '=6*asin 0.5' etc. This commit removes the letter check in case the user had explicitly typed the '=', restoring 4.10 behavior. If I understand the letter check correctly, it is very hard to support functions in the case the user had omitted the '=' Diffs - plasma/generic/runners/calculator/calculatorrunner.cpp 0d52301 Diff: http://git.reviewboard.kde.org/r/113504/diff/ Testing --- Thanks, Christoph Feck
Re: Review Request 113504: Fix krunner calculator letter check
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113504/ --- (Updated Oct. 30, 2013, 9:33 a.m.) Status -- This change has been marked as submitted. Review request for kde-workspace and Plasma. Bugs: 326059 http://bugs.kde.org/show_bug.cgi?id=326059 Repository: kde-workspace Description --- The calculator runner now supports the syntax without the '=', so you can simply type in '3+5' and have the result. An additional commit added a letter check, so that it will not try to compute with normal text input, but this broke any calculations with any functions, such as '=6*asin 0.5' etc. This commit removes the letter check in case the user had explicitly typed the '=', restoring 4.10 behavior. If I understand the letter check correctly, it is very hard to support functions in the case the user had omitted the '=' Diffs - plasma/generic/runners/calculator/calculatorrunner.cpp 0d52301 Diff: http://git.reviewboard.kde.org/r/113504/diff/ Testing --- Thanks, Christoph Feck
Re: Adopting AppData in KDE?
Hi, what would be nice to have is information about which MIME types an application can read and write. Christoph Feck (kdepepo) KDE Quality Team
Re: Review Request 113846: fix kicontheme::list
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113846/#review43637
---
tier3/kiconthemes/src/kicontheme.cpp
<http://git.reviewboard.kde.org/r/113846/#comment31365>
Use '/' (single quotes) for single characters.
But this line also misses some QLatin1String or QStringLiteral to be
NO_ASCII_CAST safe.
- Christoph Feck
On Nov. 13, 2013, 5:33 p.m., Jonathan Riddell wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113846/
> ---
>
> (Updated Nov. 13, 2013, 5:33 p.m.)
>
>
> Review request for kdelibs and David Faure.
>
>
> Repository: kdelibs
>
>
> Description
> ---
>
> kicontheme does not find any icon themes because it misses the trailing slash
> on the directory name
>
>
> Diffs
> -
>
> tier3/kiconthemes/src/kicontheme.cpp 33261fe
>
> Diff: http://git.reviewboard.kde.org/r/113846/diff/
>
>
> Testing
> ---
>
>
> Thanks,
>
> Jonathan Riddell
>
>
Re: Moving KScreen and libkscreen to extragear
On Wednesday 13 November 2013 21:16:01 Ben Cooksley wrote: > Based on Alex's request, I have now moved libkscreen and kscreen to > their relevant locations in Extragear. Multiple screen support was one of the "weak spots" left in KDE 4. Nice to see it's finally fixed. Thanks to everyone involved! Next in queue: Screenlocker ;) Btw, is the plan to move KScreen to the Workspace for the Plasma 2 release? It really shouldn't be an "extra", but a standard component. But I am not sure if the plan is to split the Workspace repo or rather unify it (including Plasma-NM components, etc.). Christoph Feck (kdepepo) KDE Quality Team
Re: Review Request 113260: Port KTimeZoned to Qt5/KF5
> On Nov. 12, 2013, 10:39 a.m., Commit Hook wrote: > > This review has been submitted with commit > > 53e8e439af2483c86b21ad4d53ffe4da622e8c44 by Martin Klapetek to branch > > frameworks. Locally, I get this error: AUTOMOC: error: process for /local/build/kf5/runtime/ktimezoned/ktimezoned.moc failed: /local/git/KDE/base/kde-runtime-frameworks/ktimezoned/ktimezoned.cpp:35: Error: Plugin Metadata file "ktimezoned.json" does not exist. Declaration will be ignored moc failed... make[2]: *** [ktimezoned/CMakeFiles/kded_ktimezoned_automoc] Error 1 make[2]: Target `ktimezoned/CMakeFiles/kded_ktimezoned_automoc.dir/build' not remade because of errors. make[1]: *** [ktimezoned/CMakeFiles/kded_ktimezoned_automoc.dir/all] Error 2 Any idea? - Christoph --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113260/#review43507 --- On Nov. 12, 2013, 10:39 a.m., Martin Klapetek wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/113260/ > --- > > (Updated Nov. 12, 2013, 10:39 a.m.) > > > Review request for KDE Runtime, KDE Frameworks, Plasma, and John Layt. > > > Repository: kde-runtime > > > Description > --- > > Originally I wanted to port KTimeZoned 1:1 to Qt5/KF5, but then I found out > that all the stuff KTZD was doing was added in QTimeZone, that includes > reading correct system files/env variables to obtain the timezone and > returning the proper system zone (KTZD did all this by itself). It also > doesn't need to parse the timezone files itself or watch for their changes as > QTimeZone objects are not stored. > > So now it's just a thin module watching /etc/timezone (used by Debian-based > distros) and /etc/localtime (used by eg. Fedora or Suse, but also by Debian > in conjunction with /etc/timezone) for changes and if it detects a change, it > checks if the new timezone is really different and if it is, it sends out a > DBus signal "timeZoneChange". I changed it from "configChanged" as I think > "timeZoneChanged" makes way more sense. > > I didn't touch the Windows part as I have no way to test, would be nice if > someone could help with that. > > EDIT: I removed the other two DBus signals which were not used and I'm unsure > KTZD is the correct place for that now anyway. The only usage in > KSystemTimeZone can be replaced by own KDirWatch instance. > > > Diffs > - > > CMakeLists.txt a5ec93d > ktimezoned/CMakeLists.txt bafc85e > ktimezoned/ktimezoned.h ff21807 > ktimezoned/ktimezoned.cpp f380c09 > ktimezoned/ktimezoned_win.h 26e21cc > ktimezoned/ktimezoned_win.cpp cadfe3a > ktimezoned/ktimezonedbase.h ca00aca > ktimezoned/org.kde.KTimeZoned.xml daaa0b7 > > Diff: http://git.reviewboard.kde.org/r/113260/diff/ > > > Testing > --- > > Tested by changing the timezone in different ways, change was detected and > signalled out. > > > Thanks, > > Martin Klapetek > >
Re: Review Request 113260: Port KTimeZoned to Qt5/KF5
> On Nov. 12, 2013, 10:39 a.m., Commit Hook wrote: > > This review has been submitted with commit > > 53e8e439af2483c86b21ad4d53ffe4da622e8c44 by Martin Klapetek to branch > > frameworks. > > Christoph Feck wrote: > Locally, I get this error: > > AUTOMOC: error: process for > /local/build/kf5/runtime/ktimezoned/ktimezoned.moc failed: > /local/git/KDE/base/kde-runtime-frameworks/ktimezoned/ktimezoned.cpp:35: > Error: Plugin Metadata file "ktimezoned.json" does not exist. Declaration > will be ignored > > moc failed... > make[2]: *** [ktimezoned/CMakeFiles/kded_ktimezoned_automoc] Error 1 > make[2]: Target `ktimezoned/CMakeFiles/kded_ktimezoned_automoc.dir/build' > not remade because of errors. > make[1]: *** [ktimezoned/CMakeFiles/kded_ktimezoned_automoc.dir/all] > Error 2 > > Any idea? > > Martin Klapetek wrote: > I know other folks seen this too, last time I've heard it might be a > "race condition" issue with -j>1 build (the json file gets generated only > after building the file that's actually including it). I think Aurelien was > looking into that, dunno if he made any progress though. It's indeed a "use before it's built", because when I run try to build it again (on the same build dir) it works. A clean build, however, reliably reproduces this error, even without using "-j" make option. - Christoph --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113260/#review43507 --- On Nov. 12, 2013, 10:39 a.m., Martin Klapetek wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/113260/ > --- > > (Updated Nov. 12, 2013, 10:39 a.m.) > > > Review request for KDE Runtime, KDE Frameworks, Plasma, and John Layt. > > > Repository: kde-runtime > > > Description > --- > > Originally I wanted to port KTimeZoned 1:1 to Qt5/KF5, but then I found out > that all the stuff KTZD was doing was added in QTimeZone, that includes > reading correct system files/env variables to obtain the timezone and > returning the proper system zone (KTZD did all this by itself). It also > doesn't need to parse the timezone files itself or watch for their changes as > QTimeZone objects are not stored. > > So now it's just a thin module watching /etc/timezone (used by Debian-based > distros) and /etc/localtime (used by eg. Fedora or Suse, but also by Debian > in conjunction with /etc/timezone) for changes and if it detects a change, it > checks if the new timezone is really different and if it is, it sends out a > DBus signal "timeZoneChange". I changed it from "configChanged" as I think > "timeZoneChanged" makes way more sense. > > I didn't touch the Windows part as I have no way to test, would be nice if > someone could help with that. > > EDIT: I removed the other two DBus signals which were not used and I'm unsure > KTZD is the correct place for that now anyway. The only usage in > KSystemTimeZone can be replaced by own KDirWatch instance. > > > Diffs > - > > CMakeLists.txt a5ec93d > ktimezoned/CMakeLists.txt bafc85e > ktimezoned/ktimezoned.h ff21807 > ktimezoned/ktimezoned.cpp f380c09 > ktimezoned/ktimezoned_win.h 26e21cc > ktimezoned/ktimezoned_win.cpp cadfe3a > ktimezoned/ktimezonedbase.h ca00aca > ktimezoned/org.kde.KTimeZoned.xml daaa0b7 > > Diff: http://git.reviewboard.kde.org/r/113260/diff/ > > > Testing > --- > > Tested by changing the timezone in different ways, change was detected and > signalled out. > > > Thanks, > > Martin Klapetek > >
Re: Review Request 110687: DrKonqi should check for disabled version as the very first step in the reporting assistant.
> On May 28, 2013, 11:06 a.m., Martin Gräßlin wrote: > > Could you please get some feedback from packagers. I'm not sure whether > > they like words like "unmaintained" and "upgrade". The fact that we as > > upstream don't accept bugs doesn't mean it's unmaintained by the distro and > > it's not said that one could upgrade (think of Debian Stable). Jekyll, has this been discussed on the packagers list? - Christoph --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110687/#review33280 --- On June 5, 2013, 10:05 a.m., Jekyll Wu wrote: > > --- > 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. > > > Bugs: 315073 > http://bugs.kde.org/show_bug.cgi?id=315073 > > > Repository: kde-runtime > > > 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. > > > > Diffs > - > > 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 > >
Review Request 113931: Fix process list to start already sorted
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113931/ --- Review request for kde-workspace and John Tapsell. Bugs: 282636 http://bugs.kde.org/show_bug.cgi?id=282636 Repository: kde-workspace Description --- Quoting the bug report: "When starting System Monitor, the process list is unsorted. It only gets sorted after the first timer tick. Waiting before sorting only makes sense when sorting by CPU load, where the load is not available before the fist tick. For all other types of sorting (name, username, memory, etc.) all data is available immediately, so the list should appear already sorted when starting up." Diffs - libs/ksysguard/processui/ksysguardprocesslist.cpp ed2c1ff Diff: http://git.reviewboard.kde.org/r/113931/diff/ Testing --- I use this patch since some weeks. Thanks, Christoph Feck
Re: Review Request 113965: Possible fix for bug 321100
> On Nov. 20, 2013, 6:02 p.m., Albert Astals Cid wrote: > > I don't see why this should fix anything. Do you think anyone in the bug > > can provide a valgrind trace to better understand why it's crashing? See also https://git.reviewboard.kde.org/r/102981/ which has some discussion and links to related bugs. - Christoph --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113965/#review44060 --- On Nov. 20, 2013, 9:40 a.m., Boudewijn Rempt wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/113965/ > --- > > (Updated Nov. 20, 2013, 9:40 a.m.) > > > Review request for kdelibs. > > > Bugs: 321100 > http://bugs.kde.org/show_bug.cgi?id=321100 > > > Repository: kdelibs > > > Description > --- > > While I haven't been able to reproduce the issue on Linux, many Krita users > encounter a crash in the destructor of KArchiveDirectoryPrivate, where all > entries are removed with qDeleteAll. > > This patch removes the use of qDeleteAll. > > I'm not 100% sure whether this is correct, but it works for me with the > Windows build of kdelibs I use. > > > Diffs > - > > kdecore/io/karchive.cpp 88e1de0 > > Diff: http://git.reviewboard.kde.org/r/113965/diff/ > > > Testing > --- > > > Thanks, > > Boudewijn Rempt > >
Re: Review Request 113965: Possible fix for bug 321100
> On Nov. 20, 2013, 6:02 p.m., Albert Astals Cid wrote: > > I don't see why this should fix anything. Do you think anyone in the bug > > can provide a valgrind trace to better understand why it's crashing? > > Christoph Feck wrote: > See also https://git.reviewboard.kde.org/r/102981/ which has some > discussion and links to related bugs. > > Albert Astals Cid wrote: > Why is it related? Who is modifying the entries variable? It's used in 4 > places in the file, and actually there's no way to remove stuff from it, so I > don't see how it is related to the bug you point. They are only related because replacing qDeleteAll() with manual deletion fixed the crash for Boudewijn. Since my understanding ended there, I suggested to post a review request. - Christoph --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113965/#review44060 --- On Nov. 20, 2013, 9:40 a.m., Boudewijn Rempt wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/113965/ > --- > > (Updated Nov. 20, 2013, 9:40 a.m.) > > > Review request for kdelibs. > > > Bugs: 321100 > http://bugs.kde.org/show_bug.cgi?id=321100 > > > Repository: kdelibs > > > Description > --- > > While I haven't been able to reproduce the issue on Linux, many Krita users > encounter a crash in the destructor of KArchiveDirectoryPrivate, where all > entries are removed with qDeleteAll. > > This patch removes the use of qDeleteAll. > > I'm not 100% sure whether this is correct, but it works for me with the > Windows build of kdelibs I use. > > > Diffs > - > > kdecore/io/karchive.cpp 88e1de0 > > Diff: http://git.reviewboard.kde.org/r/113965/diff/ > > > Testing > --- > > > Thanks, > > Boudewijn Rempt > >
Re: Review Request 113969: Do not assume every items have the same height
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113969/#review44071 --- I love people who report bugs, and one year later come up with a patch :P Anyway, nice analysis, and this probably also fixes bug 290971, but have not tested it yet. - Christoph Feck On Nov. 20, 2013, 9:47 p.m., Yichao Yu wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/113969/ > --- > > (Updated Nov. 20, 2013, 9:47 p.m.) > > > Review request for kdelibs, David Faure, Rafael Fernández López, and Michael > Pyne. > > > Bugs: 309780 > http://bugs.kde.org/show_bug.cgi?id=309780 > > > Repository: kdelibs > > > Description > --- > > 1. the offset addjust in `KCategorizedView::indexAt` was a no-op (it operates > on a temporary variable and is not needed). > 2. KCategorizedView::indexAt (effectively) assumes all items has the same > height when doing bsearch and therefore failed to handle some cases when the > text takes multiple lines as shown in the bug report. > > This patch removes the no-op and add special check for items in the same row > on the left (or on the right for RightToLeft layout) in order to determine > which way the bsearch should go. > > > Diffs > - > > kdeui/itemviews/kcategorizedview.cpp 010bcbc > > Diff: http://git.reviewboard.kde.org/r/113969/diff/ > > > Testing > --- > > Compiles and fixes the problem. > Tested with systemsettings in the following conditions: > 1. single row in each category. > 2. multiple rows in each category. > 3. scrollbar not at the top. > > > Thanks, > > Yichao Yu > >
Re: Review Request 114017: Possibly fix crash with horizontal wheel on tabs
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114017/ --- (Updated Nov. 26, 2013, 11:22 a.m.) Review request for kdelibs. Changes --- Basic testing. Bugs: 314082 http://bugs.kde.org/show_bug.cgi?id=314082 Repository: kdelibs Description --- Details at bug 314082. >From how I understand the problem, we should not sent the fake event for >horizontal scrolling, because it is not handled by the tabbar code. Someone >please confirm it fixes the problem. Diffs - kdeui/widgets/ktabwidget.cpp 49dc293 Diff: http://git.reviewboard.kde.org/r/114017/diff/ Testing (updated) --- Fixes the crash, according to a tester. Thanks, Christoph Feck
