Re: Patch for exception.h

Hi Friedrich >No proper insight into Threadweaver myself here. If no-one else picks >up your >question here on the ML in the next days I propose to file a bug then, >hoping >that someone with clue might have time one day to pick up this issue. Thanks -- Mit freundlichem G

Re: Patch for exception.h

g a job was only possible by throwing Threadweaver::JobFailed(). I didn't dig deeper in the source than job.cpp, where throwing an exception is catched by the executor, which sets the state accordingly. Is it a bug or just not documented corrected? -- Mit freundlichem Gruss Christian Riggenbach

Patch for exception.h

e me for posting a link to github, but it is a really small fix: https://github.com/eringerli/threadweaver/commit/ f7e480e9bd9a3a6dd7f0bed67a4f853e2e339c95[1] -- mit freundlichem Gruss Christian Riggenbach [1] https://github.com/eringerli/threadweaver/commit/ f7e480e9bd9a3a6dd7f0bed67a4f853e2e339c95

D29049: add telephant icon

muesli accepted this revision. This revision is now accepted and ready to land. REPOSITORY R266 Breeze Icons BRANCH telephant (branched from master) REVISION DETAIL https://phabricator.kde.org/D29049 To: mbruchert, muesli, #vdg Cc: ngraham, kde-frameworks-devel, LeGast00n, cblack, michael

D29049: add telephant icon

muesli added a comment. Gets my approval! I assume those symlinks from 'com.fribbledom.telephant.svg' are intentional to match the appstream ID? REPOSITORY R266 Breeze Icons REVISION DETAIL https://phabricator.kde.org/D29049 To: mbruchert, muesli, #vdg Cc: kde-frameworks-devel, LeGast00

D24401: Use exposed DBus methods to switch activities in CLI

This revision was automatically updated to reflect the committed changes. Closed by commit R6:a1c973c01ece: Use exposed DBus methods to switch activities in CLI (authored by muesli). REPOSITORY R6 KActivities CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D24401?vs=67281&id=75776 REV

D24401: Use exposed DBus methods to switch activities in CLI

muesli added a comment. @ivan @ngraham Ok, with 5.18 out I think we can finally review this one :-) REPOSITORY R6 KActivities REVISION DETAIL https://phabricator.kde.org/D24401 To: muesli, ivan Cc: ngraham, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, bruns

D24401: Use exposed DBus methods to switch activities in CLI

muesli added a comment. Actually I'm mistaken, we can't merge this just yet. We'll still need to wait for the Plasma 5.18 release. REPOSITORY R6 KActivities REVISION DETAIL https://phabricator.kde.org/D24401 To: muesli, ivan Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham,

D24401: Use exposed DBus methods to switch activities in CLI

muesli added a comment. @ivan Do you think we can merge this now? REPOSITORY R6 KActivities REVISION DETAIL https://phabricator.kde.org/D24401 To: muesli, ivan Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D25996: KRemoteEncoding::encoding: don't return temporary. Found with clazy.

This revision was automatically updated to reflect the committed changes. Closed by commit R241:d80cb8c96eef: KRemoteEncoding::encoding: don't return temporary. Found with clazy. (authored by chehrlic). REPOSITORY R241 KIO CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D25996?vs=71529

D25997: KFilePlacesModel: properly parent tagsLister to avoid memleak. Introduced with D7700

This revision was automatically updated to reflect the committed changes. Closed by commit R241:be9537998890: KFilePlacesModel: properly parent tagsLister to avoid memleak. Introduced with… (authored by chehrlic). REPOSITORY R241 KIO CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D259

D25995: HTTP ioslave: call correct base class in virtual_hook(). The base of HTTP ioslave is TCPSlaveBase, not SlaveBase.

This revision was automatically updated to reflect the committed changes. Closed by commit R241:6f1628706490: HTTP ioslave: call correct base class in virtual_hook(). The base of HTTP… (authored by chehrlic). REPOSITORY R241 KIO CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D25995?vs

D25996: KRemoteEncoding::encoding: don't return temporary. Found with clazy.

chehrlic added a comment. It was clazy, not me - just wanted to fix a memleak in kio :) REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D25996 To: chehrlic, thiago, dfaure Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D25997: KFilePlacesModel: properly parent tagsLister to avoid memleak. Introduced with D7700

chehrlic added reviewers: dfaure, nicolasfella, ngraham, Dolphin. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D25997 To: chehrlic, dfaure, nicolasfella, ngraham, #dolphin Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D25996: KRemoteEncoding::encoding: don't return temporary. Found with clazy.

chehrlic added reviewers: thiago, dfaure. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D25996 To: chehrlic, thiago, dfaure Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D25995: HTTP ioslave: call correct base class in virtual_hook(). The base of HTTP ioslave is TCPSlaveBase, not SlaveBase.

chehrlic added reviewers: dfaure, ngraham, Dolphin. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D25995 To: chehrlic, dfaure, ngraham, #dolphin Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D25997: KFilePlacesModel: properly parent tagsLister to avoid memleak. Introduced with D7700

chehrlic created this revision. Herald added a project: Frameworks. Herald added a subscriber: kde-frameworks-devel. chehrlic requested review of this revision. REPOSITORY R241 KIO BRANCH kfileplacesmodel REVISION DETAIL https://phabricator.kde.org/D25997 AFFECTED FILES src/filewidgets/

D25996: KRemoteEncoding::encoding: don't return temporary. Found with clazy.

chehrlic created this revision. Herald added a project: Frameworks. Herald added a subscriber: kde-frameworks-devel. chehrlic requested review of this revision. REPOSITORY R241 KIO BRANCH remoteencoding REVISION DETAIL https://phabricator.kde.org/D25996 AFFECTED FILES src/core/kremoteen

D25995: HTTP ioslave: call correct base class in virtual_hook(). The base of HTTP ioslave is TCPSlaveBase, not SlaveBase.

chehrlic created this revision. Herald added a project: Frameworks. Herald added a subscriber: kde-frameworks-devel. chehrlic requested review of this revision. REPOSITORY R241 KIO BRANCH http REVISION DETAIL https://phabricator.kde.org/D25995 AFFECTED FILES src/ioslaves/http/http.cpp

D25994: KFilePlacesModel: properly parent tagsLister to avoid memleak. Introduced with D7700

chehrlic abandoned this revision. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D25994 To: chehrlic Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D25994: KFilePlacesModel: properly parent tagsLister to avoid memleak. Introduced with D7700

chehrlic created this revision. Herald added a project: Frameworks. Herald added a subscriber: kde-frameworks-devel. chehrlic requested review of this revision. REVISION SUMMARY HTTP ioslave: call correct base class in virtual_hook(). The base of HTTP ioslave is TCPSlaveBase, not SlaveBase.

D7700: Show list of tags in PlacesView

chehrlic added inline comments. INLINE COMMENTS > kfileplacesmodel.cpp:172 > + tags(), > + tagsLister(new KCoreDirLister()) > { While I way playing around with asan, I got a report that tagsLister is leaking. I can't see a deletion of this object anywhere, even in current

D24841: Use modern way to set the C/CXX standad

chehrlic added a comment. I would also use CMAKE_CXX_STANDARD_REQUIRED to make sure the compiler actually *can* c++11, otherwise the flag is only added when the compiler supports it. Should not make much difference nowadays but since it's in ECM... REPOSITORY R240 Extra CMake Modules REVI

Developing an GLFW app that links makes use of KWindowEffects?

nd code duplication). Many thanks in advance, Christian Parpart.

D24401: Use exposed DBus methods to switch activities in CLI

muesli added a comment. Careful: we must _not_ land this before the next Plasma release. REPOSITORY R6 KActivities REVISION DETAIL https://phabricator.kde.org/D24401 To: muesli, ivan Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D24401: Use exposed DBus methods to switch activities in CLI

muesli created this revision. muesli added a reviewer: ivan. Herald added a project: Frameworks. Herald added a subscriber: kde-frameworks-devel. muesli requested review of this revision. REVISION SUMMARY Since https://phabricator.kde.org/D22381 has landed kactivitymanagerd now exposes methods

D23789: RFC: Add ECMGenerateExportHeaders, for improved handling of deprecated API

chehrlic added a comment. In D23789#538985 , @kossebau wrote: > >> - why has all Qt code not yet been adapted to QT_DEPRECATED_VERSION/QT_DEPRECATED_VERSION_X, are there places where those macros should not be used, but the version-less ones?

D23789: RFC: Add ECMGenerateExportHeaders, for improved handling of deprecated API

chehrlic added a comment. In D23789#536338 , @kossebau wrote: > Actual questions I have: > > - why is QT_DEPRECATED_WARNINGS_SINCE not officially documented? like, any plans to change that macro to something else? Just forgot it (and

D22370: Simplify previous-/nextActivity code in kactivities-cli

This revision was automatically updated to reflect the committed changes. Closed by commit R6:c450f09e8921: Simplify previous-/nextActivity code in kactivities-cli (authored by muesli). REPOSITORY R6 KActivities CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D22370?vs=61499&id=61502

D22370: Simplify previous-/nextActivity code in kactivities-cli

muesli added a reviewer: ivan. REPOSITORY R6 KActivities REVISION DETAIL https://phabricator.kde.org/D22370 To: muesli, ivan Cc: kde-frameworks-devel, LeGast00n, michaelh, ngraham, bruns

D22370: Simplify previous-/nextActivity code in kactivities-cli

muesli created this revision. Herald added a project: Frameworks. Herald added a subscriber: kde-frameworks-devel. muesli requested review of this revision. REVISION SUMMARY Removed unnecessary bool found and directly return from inner loop. REPOSITORY R6 KActivities BRANCH kactivities-cli

D20059: Take clang-cl into account.

cmollekopf added a comment. FWIW, I have meanwhile used this patch to build all kube dependencies on linux and osx as well, and it seems like it doesn't break anything. I think clang-cl should receive all arguments it understands with this patch. REPOSITORY R240 Extra CMake Modules RE

D20059: Take clang-cl into account.

cmollekopf added a comment. There was already an earlier (abandoned) attempt at this: https://git.reviewboard.kde.org/r/128779 REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D20059 To: cmollekopf Cc: kde-frameworks-devel, kde-buildsystem, michaelh, ngrah

D20059: Take clang-cl into account.

cmollekopf created this revision. Herald added projects: Frameworks, Build System. Herald added subscribers: kde-buildsystem, kde-frameworks-devel. cmollekopf requested review of this revision. REVISION SUMMARY clang-cl is an MSVC compatible frontend for clang, and as such takes MSVC style arg

D11346: Only set iconText() if actually changed

chehrlic accepted this revision. chehrlic added a comment. This revision is now accepted and ready to land. This should at least fix the most cases as described in the bug report :) REPOSITORY R236 KWidgetsAddons REVISION DETAIL https://phabricator.kde.org/D11346 To: cfeck, #frameworks,

D11137: overflow-menu as view-more-symbolic, and horizontal

Fuchs added a comment. Yes, I very much like the overflow and the usage you describe, as per the discussion on Telegram and https://phabricator.kde.org/D11231, I think mixer is however not an example where it should be used, because in the mixer it's not an overflow of functionality, but rat

D7926: Remove pf.path() from container before the reference got screwed up by it.remove()

chehrlic closed this revision. REPOSITORY R293 Baloo REVISION DETAIL https://phabricator.kde.org/D7926 To: chehrlic, broulik Cc: #frameworks

D7926: Remove pf.path() from container before the reference got screwed up by it.remove()

chehrlic created this revision. Restricted Application added a project: Frameworks. Restricted Application added a subscriber: Frameworks. REVISION SUMMARY With https://phabricator.kde.org/R293:a75db7aedfcd356b027774e0dc156c334d4cb869 I introduced a crash when removing a watched directory. T

Re: Review Request 129186: [baloo] Speedup Positioncodec::encode()

marked as submitted. Review request for Baloo, KDE Frameworks and Vishesh Handa. Changes --- Submitted with commit 2717080c46072b2a2998cb7d043a7cbcefa6a843 by Christian Ehrlicher to branch master. Repository: baloo Description --- This patch speeds up PostingCodec::encode() by a

Re: Review Request 129186: [baloo] Speedup Positioncodec::encode()

/coding.cpp 5961077 Diff: https://git.reviewboard.kde.org/r/129186/diff/ Testing --- positoncodectest calculates the same md5sum as before. Thanks, Christian Ehrlicher

Re: Review Request 129186: [baloo] Speedup Positioncodec::encode()

/ Testing --- positoncodectest calculates the same md5sum as before. Thanks, Christian Ehrlicher

Re: Review Request 126392: Fix some Clazy warnings in kcoreaddons

const? Or would this be an ABI breakage? src/lib/text/kmacroexpander.cpp (line 74) <https://git.reviewboard.kde.org/r/126392/#comment61703> Qt5 has a new overload QStringList::join(QChar) -> join(QLatin1Char(' ')) - Christian Ehrlicher On Dez. 18

Re: Future Frameworks Release BoF at Akademy

Thanks! I'll be there. Cheers, Christian On Thu, Jul 2, 2015, at 11:57 AM, Kevin Ottens wrote: > Hello, > > Since the discussion on mailing lists regarding the "Future frameworks > releases" thread couldn't get to a proper conclusion and we agreed on >

Re: Future frameworks releases

nitial thread better, but details aside this is spot on). I think however it would be a bad idea to create a second set of libraries next to frameworks, because that would IMO defeat the purpose of frameworks. If frameworks is a collection of high quality kde/qt libraries, it shouldn't have a competitor that does essentially the same thing just without the versioning policy. This would create needless confusion about where to put or find libraries, and reduce the attractivity of both propositions. Cheers, Christian ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Versioning of Frameworks

On Tue, May 12, 2015, at 09:22 AM, David Faure wrote: > On Monday 11 May 2015 15:51:20 Christian Mollekopf wrote: > > I think there are two possibilities: > > * "master" is the development branch and we have a separate "release" > > branch > >

Re: Versioning of Frameworks

On Mon, May 11, 2015, at 02:42 PM, David Faure wrote: > On Monday 11 May 2015 11:57:02 Christian Mollekopf wrote: > > But that doesn't necessarily mean they can't be part of the same > > distribution mechanism. > > If you simply take a snapshot of all

Re: Versioning of Frameworks

On Mon, May 11, 2015, at 12:31 AM, David Faure wrote: > On Monday 11 May 2015 00:13:27 Christian Mollekopf wrote: > > > Are you volunteering, or just making demands for others to do work for > > > you? > > > > I'm volunteering to do the maintenance and rel

Re: Versioning of Frameworks

On Sun, May 10, 2015, at 11:13 PM, David Faure wrote: > On Sunday 10 May 2015 22:31:10 Alexander Neundorf wrote: > > There I have Qt available, as Christian says, it feels like a system > > library, our application is built on it. > > Well, I wish you would see KF5 as a na

Re: Versioning of Frameworks

On Mon, May 11, 2015, at 12:05 AM, Albert Astals Cid wrote: > El Diumenge, 10 de maig de 2015, a les 23:47:32, Christian Mollekopf va > escriure: > > On Sun, May 10, 2015, at 11:23 PM, Albert Astals Cid wrote: > > > El Diumenge, 10 de maig de 2015, a les 22:31:10,

Re: Versioning of Frameworks

On Sun, May 10, 2015, at 11:23 PM, Albert Astals Cid wrote: > El Diumenge, 10 de maig de 2015, a les 22:33:30, Christian Mollekopf va > escriure: > > On Sun, May 10, 2015, at 03:39 PM, David Faure wrote: > > > On Sunday 10 May 2015 12:36:53 Christian Mollekopf wrote: >

Re: Versioning of Frameworks

On Sun, May 10, 2015, at 11:23 PM, Albert Astals Cid wrote: > El Diumenge, 10 de maig de 2015, a les 22:31:10, Alexander Neundorf va > escriure: > > On Sunday, May 10, 2015 15:39:02 David Faure wrote: > > > On Sunday 10 May 2015 12:36:53 Christian Mollekopf wrote: > &g

Re: Versioning of Frameworks

On Sun, May 10, 2015, at 03:39 PM, David Faure wrote: > On Sunday 10 May 2015 12:36:53 Christian Mollekopf wrote: > > * I'd consider Qt to be a lower level library. Qt mostly provides > > fundamentals just like libc or the STL, > > and it's therefore okay for m

Re: Versioning of Frameworks

pective framework instead of running in my own circles in wherever I use the framework. I therefore need to be able to use the results of that work on all my target platforms, otherwise working on the framework is just having me implement the same thing twice. So as a summary, it's only fin

Re: Versioning of Frameworks

On Wed, May 6, 2015, at 01:42 PM, Jan Kundrát wrote: > Hi Christian, Hi Jan, > I think that the stuff you're looking for (reducing version churn) can > also > be provided by having stable branches for selected parts of KF5. > > IMHO this can be quite an elegant solut

Re: Versioning of Frameworks

anyways doesn't work because developers don't care, but that is first of not generally true, and by allowing for a version number we would give the individual maintainers at least the chance to do it properly. Appart from the communcation aspect, we make library updates unnecessarily risky because of the complete frameworks dependency tree getting pulled in (so you have to pull in 8 updates instead of 1), which is probably the biggest problem in an enterprise environment. Cheers, Christian ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Versioning of Frameworks

On Tue, May 5, 2015, at 01:31 PM, Martin Gräßlin wrote: > On Tuesday 05 May 2015 13:20:25 Christian Mollekopf wrote: > > On Tue, May 5, 2015, at 12:09 PM, Martin Gräßlin wrote: > > > On Tuesday 05 May 2015 11:33:03 Christian Mollekopf wrote: > > > > What the regula

Re: Versioning of Frameworks

On Tue, May 5, 2015, at 12:09 PM, Martin Gräßlin wrote: > On Tuesday 05 May 2015 11:33:03 Christian Mollekopf wrote: > > What the regular releases IMO should be doing, is to take the latest > > version from the "always releasable" master branch, > > and be d

Re: Versioning of Frameworks

On Tue, May 5, 2015, at 12:11 PM, Martin Gräßlin wrote: > On Tuesday 05 May 2015 11:45:19 Christian Mollekopf wrote: > > On Wed, Apr 29, 2015, at 09:45 PM, David Faure wrote: > > > On Wednesday 29 April 2015 15:00:32 Christian Mollekopf wrote: > > > > You do

Re: Versioning of Frameworks

On Wed, Apr 29, 2015, at 09:45 PM, David Faure wrote: > On Wednesday 29 April 2015 15:00:32 Christian Mollekopf wrote: > > You don't have to maintain any other combinations that what you already > > do. > > Just because the cmake versions aren't automatically bumpe

Re: Versioning of Frameworks

Hey David, Sorry for the late response. On Wed, Apr 29, 2015, at 08:34 PM, David Faure wrote: > On Tuesday 28 April 2015 12:17:00 Christian Mollekopf wrote: > > Our dependency tree is now indeed reduced, but if we want to update a > > single library, we are forced to update all li

Re: Versioning of Frameworks

On Wed, Apr 29, 2015, at 01:29 PM, Martin Gräßlin wrote: > On Wednesday 29 April 2015 12:19:18 Christian Mollekopf wrote: > > On Wed, Apr 29, 2015, at 11:03 AM, Martin Gräßlin wrote: > > > On Wednesday 29 April 2015 09:35:12 Christian Mollekopf wrote: > > > > On

Re: Versioning of Frameworks

On Wed, Apr 29, 2015, at 11:03 AM, Martin Gräßlin wrote: > On Wednesday 29 April 2015 09:35:12 Christian Mollekopf wrote: > > On Wed, Apr 29, 2015, at 12:11 AM, Aleix Pol wrote: > > > On Tue, Apr 28, 2015 at 12:17 PM, Christian Mollekopf > > > wrote: > > >

Re: Versioning of Frameworks

On Wed, Apr 29, 2015, at 12:11 AM, Aleix Pol wrote: > On Tue, Apr 28, 2015 at 12:17 PM, Christian Mollekopf > wrote: > > Hi Christian, > I understand your needs, I've seen similar complaints before. > > Letting frameworks depend on different versions could make s

Versioning of Frameworks

en just approach the individual maintainers. It's of course quite possible that I don't understand the requirements of others, so I'm interested to hear about that as well =) Cheers, Christian [0] http://semver.org/ Our dependency tree is roughly (it's currently larger,

Naming covention for framworks

ourse only apply to namespaces, the installed cmake files and project name, but not the repository. I assume that is okay? Or is there a rule for first letter upper-case and all other lower-case? Cheers, Christian ___ Kde-frameworks-devel mailing list Kde-