D8848: do not install development tool to aggregate desktop files

This revision was automatically updated to reflect the committed changes. Closed by commit R304:f4f245325cc0: do not install development tool to aggregate desktop files (authored by sitter). REPOSITORY R304 KNewStuff CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D8848?vs=22469=22505

D8848: do not install development tool to aggregate desktop files

sitter created this revision. sitter added reviewers: Frameworks, whiting, gregormi. Restricted Application added a project: Frameworks. REVISION SUMMARY it's not useful in production REPOSITORY R304 KNewStuff BRANCH master REVISION DETAIL https://phabricator.kde.org/D8848 AFFECTED

Re: What controls the default ordering of which application handles an opened file?

On Thu, Nov 16, 2017 at 4:24 AM, Nate Graham wrote: > Howdy all, > I'm working on adding Krita file support to Gwenview > (https://phabricator.kde.org/D8751) and my patch works, but has the side > effect of causing Krita files to prefer being opened in Gwenview rather than

D8825: do not show edit bookmarks action if keditbookmarks is not installed

sitter updated this revision to Diff 22443. sitter added a comment. rebased REPOSITORY R294 KBookmarks CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D8825?vs=22379=22443 BRANCH master REVISION DETAIL https://phabricator.kde.org/D8825 AFFECTED FILES

D8824: port from deprecated KAuthorized::authorizeKAction to authorizeAction

This revision was automatically updated to reflect the committed changes. Closed by commit R294:378808a575d7: port from deprecated KAuthorized::authorizeKAction to authorizeAction (authored by sitter). REPOSITORY R294 KBookmarks CHANGES SINCE LAST UPDATE

D8825: do not show edit bookmarks action if keditbookmarks is not installed

sitter added inline comments. INLINE COMMENTS > apol wrote in kbookmarkmenu_p.h:42 > Why not in the cpp file? It's used in 2 difference cpps. REPOSITORY R294 KBookmarks REVISION DETAIL https://phabricator.kde.org/D8825 To: sitter, #frameworks Cc: apol

D8825: do not show edit bookmarks action if keditbookmarks is not installed

sitter created this revision. sitter added a reviewer: Frameworks. Restricted Application added a project: Frameworks. REVISION SUMMARY keditbookmarks lives in applications, making it very likely that it is not installed. this does already raise an error window explaining that the binary is

D8824: port from deprecated KAuthorized::authorizeKAction to authorizeAction

sitter created this revision. sitter added a reviewer: Frameworks. Restricted Application added a project: Frameworks. REVISION SUMMARY authorizeKAction is internally calling authorizeAction, so simply switch the function calls to the new name fixes excessive deprecation warnings getting

Re: http://commitfilter.kde.org/ ?

See http://markmail.org/thread/hekkp2rcdvir732q http://markmail.org/thread/b6neyhjak2h4g2yd On Sun, Oct 29, 2017 at 9:47 PM, Martin Koller wrote: > Should http://commitfilter.kde.org/ still exist ? > Currently I get "unknown host" > > -- > Best regards/Schöne Grüße > > Martin >

Re: Frameworks release schedule?

On Wed, Oct 25, 2017 at 10:35 AM, laurent Montel wrote: > Hi, > I send this email to kde-frameworks-devel > > It's the correct ML for having an answer about it > > Regards. > > Le mercredi 25 octobre 2017, 09:29:58 CEST Valorie Zimmerman a écrit : >> Hello folks, with my Kubuntu

Re: Frameworks release schedule?

On Wed, Oct 25, 2017 at 10:35 AM, laurent Montel wrote: > Hi, > I send this email to kde-frameworks-devel > > It's the correct ML for having an answer about it > > Regards. > > Le mercredi 25 octobre 2017, 09:29:58 CEST Valorie Zimmerman a écrit : >> Hello folks, with my Kubuntu

D5032: drop examples dir

This revision was automatically updated to reflect the committed changes. Closed by commit R308:5ea3c8759505: drop examples dir (authored by sitter). CHANGED PRIOR TO COMMIT https://phabricator.kde.org/D5032?vs=12428=19968#toc REPOSITORY R308 KRunner CHANGES SINCE LAST UPDATE

Re: qqc2-desktop-style as framework

Mh > set(CMAKE_LIBRARY_OUTPUT_DIRECTORY I don't think that will do for production. "This property specifies the directory into which library target files should be built. Multi-configuration generators (VS, Xcode) append a per-configuration subdirectory to the specified directory." I *think*

Re: qqc2-desktop-style as framework

On Mon, Sep 11, 2017 at 4:16 PM, Marco Martin wrote: > On Sun, Sep 10, 2017 at 3:41 PM, David Faure wrote: >> Sounds OK to me, get it moved to frameworks/ so it can be included in the >> next >> release. >> >> I notice there are no unittests (but that's always

D7430: Add unit test

sitter added a reviewer: dfaure. sitter added a subscriber: Frameworks. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D7430 To: chinmoyr, dfaure Cc: #frameworks

D7216: refactor kpackagetool away from stringy options

This revision was automatically updated to reflect the committed changes. Closed by commit R290:9597930a4596: refactor kpackagetool away from stringy options (authored by sitter). REPOSITORY R290 KPackage CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D7216?vs=17926=19045 REVISION

D6767: simplify setContents by letting Qt do more of the work

This revision was automatically updated to reflect the committed changes. Closed by commit R236:c0b452358397: simplify setContents by letting Qt do more of the work (authored by sitter). REPOSITORY R236 KWidgetsAddons CHANGES SINCE LAST UPDATE

Re: relocatable kdoctools

On Sun, Aug 27, 2017 at 8:37 PM, Luigi Toscano wrote: > Even without the if branch it would be still complicated. Ah! I think I get the complexity now. At build time we need to run our tools already and so the dtd/xsl need to be able to resolve the paths, hence the

Re: relocatable kdoctools

On Thu, Aug 24, 2017 at 3:20 PM, Ralf Habacker wrote: > 10. The conclusion of 9. is that it might also be a solution on windows > to patch only all generated files after 3. and before 4. Hm, I may be missing a piece of the puzzle in my mind, but it appears to me this

falcon has no bugzilla product

I literally can't file bug reports :(

D7462: [kiocore] assert that klauncher is running or not

sitter added a comment. You committed `(... && getuid() != reply)` rather than `||`. We'll want a fork in either scenario, so this should be `||` as suggested by David. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D7462 To: bshah, #frameworks, sitter, dfaure

Re: relocatable kdoctools

On Tue, Aug 22, 2017 at 10:47 PM, Ralf Habacker wrote: > Hi, > > I'm using the following patch to cross build kdoctools for windows > >

Re: relocatable kdoctools

On Tue, Aug 22, 2017 at 10:18 PM, Luigi Toscano <luigi.tosc...@tiscali.it> wrote: > Harald Sitter wrote: >> Ahoy ahoy >> >> I've just stumbled upon a rather puzzling situation with kdoctools. It >> has code branching to turn its assets relocatable [1] (i.e. reso

D7462: [kiocore] assert that klauncher is running or not

sitter added a comment. LGTM. Also can confirm this fixes the original problem of defunct kfileopen dialogs. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D7462 To: bshah, #frameworks, sitter, dfaure

Re: relocatable kdoctools

On Tue, Aug 22, 2017 at 11:32 AM, Ben Cooksley <bcooks...@kde.org> wrote: > On Tue, Aug 22, 2017 at 9:25 PM, Harald Sitter <sit...@kde.org> wrote: >> Ahoy ahoy > > Hi Harald, > >> >> I've just stumbled upon a rather puzzling situation with kdoctools. I

relocatable kdoctools

Ahoy ahoy I've just stumbled upon a rather puzzling situation with kdoctools. It has code branching to turn its assets relocatable [1] (i.e. resolve paths relative rather than hardcode their location). Now the weird bit about this is that it is only used on windows. The reason this puzzles me is

releaseme now relying on kdoctools for documentation installation

Hola! As per [1] the release management suite releaseme creates tarballs which rely on kdoctools to process a directory with docbooks inside. Previously releaseme manually constructed CMakeLists suitable for the documentation lineup at hand. This required an excessive amount of fairly poorly

D7216: refactor kpackagetool away from stringy options

sitter created this revision. Restricted Application added a project: Frameworks. Restricted Application added a subscriber: Frameworks. REVISION SUMMARY A notable advantage of qcommandlineoption is that using the objects the compiler makes sure that everyone is talking about the same option.

D7094: Include a module for finding qml imports as runtime dependencies

sitter accepted this revision. sitter added a comment. This revision is now accepted and ready to land. Oh it's gorgeous! REPOSITORY R240 Extra CMake Modules BRANCH master REVISION DETAIL https://phabricator.kde.org/D7094 To: apol, #build_system, #frameworks, sitter Cc: dfaure, aacid

D7094: Include a module for finding qml imports as runtime dependencies

sitter added inline comments. INLINE COMMENTS > apol wrote in ECMFindQMLModule.cmake.in:30 > Doing find_program for now. The right fix would be to change Qt to export the > `qmlplugindump` target. You still need to do "something" if qmlplugindump isn't found. Print a `message(WARNING` and/or

D7008: Don't export internal helper executables

sitter added a subscriber: apol. sitter added a comment. In https://phabricator.kde.org/D7008#133756, @habacker wrote: > In https://phabricator.kde.org/D7008#133755, @sitter wrote: > > > In https://phabricator.kde.org/D7008#133644, @sitter wrote: > > > > >

D7008: Don't export internal helper executables

sitter added a comment. In https://phabricator.kde.org/D7008#133764, @vkrause wrote: > I assume installation is done for cross-compilation, yes. For Yocto this wouldn't even be necessary though, we manually inject the host executables into the -dev packages there, for this it only

D7094: Include a module for finding qml imports as runtime dependencies

sitter added a comment. qmlplugindump not being found needs to be handled somehow. Other than that only minor nitpicks. (as always I'd also be more confident if it had a test case ;)) INLINE COMMENTS > ECMFindQMLModule.cmake.in:30 > + > +execute_process(COMMAND qmlplugindump

D7008: Don't export internal helper executables

sitter added a comment. In https://phabricator.kde.org/D7008#133644, @sitter wrote: > https://phabricator.kde.org/source/kconfig/browse/master/KF5ConfigConfig.cmake.in;023e3ecfe985e09f786134fc28793d24383998f8$11 when not xcompiling the targets are fairly useless and don't need to get

D7008: Don't export internal helper executables

sitter added subscribers: habacker, sandsmark, sitter. sitter added a comment. As per the if below the proposed change it is used for cross compiling. Subscribing original author and committer. (kind of off topic: This code should really be changed to use the `KF5_HOST_TOOLING` we

D7069: kpackagetool can now write appstream data to a file

This revision was automatically updated to reflect the committed changes. sitter marked an inline comment as done. Closed by commit R290:ef15ef0889d2: kpackagetool can now write appstream data to a file (authored by sitter). CHANGED PRIOR TO COMMIT

D7069: kpackagetool can now write appstream data to a file

sitter marked an inline comment as done. sitter added inline comments. INLINE COMMENTS > apol wrote in kpackagetool.cpp:473 > Why the `? true : false`? lol, brain fart that. REPOSITORY R290 KPackage BRANCH master REVISION DETAIL https://phabricator.kde.org/D7069 To: sitter, apol,

anyone interested in working on a KIO slave on libcloudstorage?

Hola! I've just been talking to Jean-Baptiste Kempf from VideoLAN about their new cloud library libcloudstorage [1] which is apparently fairly usable now and supports a whole bunch of main stream file storage clouds. We are thinking that a KIO slave based on this could be really awesome and give

D7069: kpackagetool can now write appstream data to a file

sitter created this revision. Restricted Application added a project: Frameworks. Restricted Application added a subscriber: Frameworks. REVISION SUMMARY Previously kpackagetool used STDOUT as output for the appstream xml data it generated. This has various problems: - cannot print

D6794: assert the testpackage appstream data validates

This revision was automatically updated to reflect the committed changes. Closed by commit R290:cd4ec70f3539: assert the testpackage appstream data validates (authored by sitter). CHANGED PRIOR TO COMMIT https://phabricator.kde.org/D6794?vs=16936=17079#toc REPOSITORY R290 KPackage CHANGES

D6793: adopt new KAboutLicense::spdx

This revision was automatically updated to reflect the committed changes. Closed by commit R290:f2127b122bd1: adopt new KAboutLicense::spdx (authored by sitter). REPOSITORY R290 KPackage CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D6793?vs=16935=17078 REVISION DETAIL

D6793: adopt new KAboutLicense::spdx

sitter added a comment. Ping? REPOSITORY R290 KPackage REVISION DETAIL https://phabricator.kde.org/D6793 To: sitter, sebas, apol Cc: #frameworks

D6793: adopt new KAboutLicense::spdx

sitter added a dependent revision: D6794: assert the testpackage appstream data validates. REPOSITORY R290 KPackage REVISION DETAIL https://phabricator.kde.org/D6793 To: sitter, sebas, apol Cc: #frameworks

D6793: adopt new KAboutLicense::spdx

sitter created this revision. Restricted Application added a project: Frameworks. Restricted Application added a subscriber: Frameworks. REVISION SUMMARY Previously we'd use the verbatim License key of the kpackage desktop file as license in appstream. This is however incorrect since

D6793: adopt new KAboutLicense::spdx

sitter added a reviewer: apol. REPOSITORY R290 KPackage REVISION DETAIL https://phabricator.kde.org/D6793 To: sitter, sebas, apol Cc: #frameworks

D6672: add KAboutLicense::spdx and introduce orLater qualification

This revision was automatically updated to reflect the committed changes. Closed by commit R244:107a7fd1a3c0: add KAboutLicense::spdx and introduce orLater qualification (authored by sitter). REPOSITORY R244 KCoreAddons CHANGES SINCE LAST UPDATE

D6624: do not crash qaccessible by causing a resize in a resize event

This revision was automatically updated to reflect the committed changes. Closed by commit R236:ca40063c4e49: do not crash qaccessible by causing a resize in a resize event (authored by sitter). CHANGED PRIOR TO COMMIT https://phabricator.kde.org/D6624?vs=16502=16860#toc REPOSITORY R236

D6624: do not crash qaccessible by causing a resize in a resize event

sitter added a comment. In https://phabricator.kde.org/D6624#126506, @cfeck wrote: > Let's say someone fixes the referenced Qt bug, and we are at a point requiring that Qt version anyway. Are you going to remove the workaround? Anyone who happens to stumble upon it can.

D6624: do not crash qaccessible by causing a resize in a resize event

sitter added a comment. In https://phabricator.kde.org/D6624#126503, @cfeck wrote: > If you are sure that your fix is "correct", then please remove the comment. From reading it, it looks like a workaround for a Qt bug. It is a workaround. It crashes because the life time of the

D6672: add KAboutLicense::spdx and introduce orLater qualification

sitter updated this revision to Diff 16858. sitter added a comment. - do not use ctor delegation, can't use that in kf5 yet - eliminate the "partial" private ctor, instead call the full private ctor from the partial public ctors. this results in defaults being implemented in the public

D6624: do not crash qaccessible by causing a resize in a resize event

sitter added a comment. In https://phabricator.kde.org/D6624#126465, @cfeck wrote: > > It probably does. > > Were you able to test? I would prefer the simpler patch. I cannot test it, because my system does not have accessibility enabled. Yes, I did not manage to crash it

D6672: add KAboutLicense::spdx and introduce orLater qualification

sitter added a comment. Ah drat. We could still get rid of the second private ctor though, by moving the defaults from the private to the public and calling the full private ctor: KAboutLicense::KAboutLicense(const KAboutData *aboutData) : d(new Private(Unknown,

D6672: add KAboutLicense::spdx and introduce orLater qualification

sitter marked 2 inline comments as done. sitter added a comment. Oh, actually. Maybe we could/should make `KAboutLicense::KAboutLicense(const KAboutData *aboutData)` delegate to the "full" public ctor. Then we can drop `Private(const KAboutData *aboutData);` entirely. Like so

D6672: add KAboutLicense::spdx and introduce orLater qualification

sitter marked 3 inline comments as done. sitter added inline comments. INLINE COMMENTS > mpyne wrote in kaboutdata.cpp:166 > Need a setter here for `_versionRestriction` I am changing this one to delegate to the other ctor actually. Not much point > mpyne wrote in kaboutdata.cpp:206 > We use

D6672: add KAboutLicense::spdx and introduce orLater qualification

sitter updated this revision to Diff 16814. sitter added a comment. rebase REPOSITORY R244 KCoreAddons CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D6672?vs=16813=16814 BRANCH spdx REVISION DETAIL https://phabricator.kde.org/D6672 AFFECTED FILES

D6672: add KAboutLicense::spdx and introduce orLater qualification

sitter updated this revision to Diff 16813. sitter marked an inline comment as done. sitter added a comment. - change "partial" Private ctor to delegate to "full" ctor so we don't have repetitive init lists - fix Private cctor to copy version restriction properly - adjust copy test to

D6700: disable compiler warning on testing deprecated function

This revision was automatically updated to reflect the committed changes. Closed by commit R244:0c33e313d5e2: disable compiler warning on testing deprecated function (authored by sitter). REPOSITORY R244 KCoreAddons CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D6700?vs=16696=16811

D6700: disable compiler warning on testing deprecated function

sitter created this revision. Restricted Application added a project: Frameworks. Restricted Application added a subscriber: Frameworks. TEST PLAN builds and doesn't warn anymore REPOSITORY R244 KCoreAddons BRANCH no-testwarning REVISION DETAIL https://phabricator.kde.org/D6700

D6700: disable compiler warning on testing deprecated function

sitter added a reviewer: mpyne. REPOSITORY R244 KCoreAddons REVISION DETAIL https://phabricator.kde.org/D6700 To: sitter, mpyne Cc: #frameworks

D6672: add KAboutLicense::spdx and introduce orLater qualification

sitter updated this revision to Diff 16694. sitter added a comment. BC constructor addition + change to enum for orlater as suggested + switch param orders to take license, then restriction, then kaboutdata kaboutdata looks and feels idiomatically like a qobject parent which also is

D6672: add KAboutLicense::spdx and introduce orLater qualification

sitter added a comment. In https://phabricator.kde.org/D6672#124995, @sitter wrote: > For convenience reasons it may actually be prudent to expose both `spdxID` and `orLater` publicly. Case in point right now appstream license information seem to be semi-expressions... they have the

D6604: add a metainfo.yaml to make ECM a proper framework

This revision was automatically updated to reflect the committed changes. Closed by commit R240:5f6aa58b8067: add a metainfo.yaml to make ECM a proper framework (authored by sitter). REPOSITORY R240 Extra CMake Modules CHANGES SINCE LAST UPDATE

D6674: use an initializer list instead of calling insert a million times

This revision was automatically updated to reflect the committed changes. Closed by commit R244:30b735056fa2: use an initializer list instead of calling insert a million times (authored by sitter). CHANGED PRIOR TO COMMIT https://phabricator.kde.org/D6674?vs=16635=16638#toc REPOSITORY R244

D6672: add KAboutLicense::spdx and introduce orLater qualification

sitter added a reviewer: mpyne. REPOSITORY R244 KCoreAddons REVISION DETAIL https://phabricator.kde.org/D6672 To: sitter, sebas, mpyne Cc: #frameworks

D6674: use an initializer list instead of calling insert a million times

sitter created this revision. Restricted Application added a project: Frameworks. Restricted Application added a subscriber: Frameworks. REVISION SUMMARY looks nicer, is probably also more optimized, and allows us to tag the dict as const. TEST PLAN builds and kaboutdatatest passes

Re: kaboutlicense api extension ::spdxId()?

On Tue, Jul 11, 2017 at 2:17 PM, Sebastian Kügler <se...@kde.org> wrote: > On dinsdag 11 juli 2017 13:41:17 CEST Harald Sitter wrote: >> I was wondering if anyone had an opinion on extending kaboutlicense >> with a ::spdxId() instance method returning the license's spdx i

D6672: add KAboutLicense::spdx and introduce orLater qualification

sitter updated this revision to Diff 16634. sitter added a comment. add missing since tag REPOSITORY R244 KCoreAddons CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D6672?vs=16633=16634 BRANCH master REVISION DETAIL https://phabricator.kde.org/D6672 AFFECTED FILES

D6672: add KAboutLicense::spdx and introduce orLater qualification

sitter updated this revision to Diff 16633. sitter added a comment. forgot to sort out BIC There is one theoretical BIC with the License ctor which has a new param. I am not sure we care about this given the ctor is private. Objections welcome but I think in the past we decied to not

D6672: add KAboutLicense::spdx and introduce orLater qualification

sitter created this revision. Restricted Application added a project: Frameworks. Restricted Application added a subscriber: Frameworks. REVISION SUMMARY External software (e.g. appstream) uses the standardized SPDX license identifiers. Seeing as they are specified and ours are not it is

D6604: add a metainfo.yaml to make ECM a proper framework

sitter updated this revision to Diff 16626. sitter added a comment. add a readme I've tried for like 2 hours to wire this into the existing docs build and get away with one README. Alas, no luck. REPOSITORY R240 Extra CMake Modules CHANGES SINCE LAST UPDATE

Re: kaboutlicense api extension ::spdxId()?

On Tue, Jul 11, 2017 at 2:17 PM, Sebastian Kügler wrote: > It does parse "and later", it's indicated by the + sign, but it's not > reflected in the enum, GPLv2+ would be mapped to GPLv2, so you're right, our > current system is lacking in that regard (but could be extended,

D6604: add a metainfo.yaml to make ECM a proper framework

sitter added a comment. In https://phabricator.kde.org/D6604#124228, @ochurlaud wrote: > At the time I thought about merging it but we would have to re-document everything in doxygen , which would be completely different from what upstream cmake does. > > The ECM page is already

D6624: do not crash qaccessible by causing a resize in a resize event

sitter added a comment. In https://phabricator.kde.org/D6624#124077, @cfeck wrote: > Reading your description on the referenced QTBUG, does it help to use a compare with previous m_columns in KCharSelectItemModel ::setColumnCount() before doing the emit dance? It probably does.

kaboutlicense api extension ::spdxId()?

Hola I was wondering if anyone had an opinion on extending kaboutlicense with a ::spdxId() instance method returning the license's spdx id [1]. Use case at hand is kpackagetool, which maps X-KDE-PluginInfo-License of (e.g.) plasma applets to appstream metadata. Appstream however uses the

D6624: do not crash qaccessible by causing a resize in a resize event

sitter added inline comments. INLINE COMMENTS > anthonyfieroni wrote in kcharselect.cpp:251 > QSignalBlocker blockResize(this) ? Block inhibits signal emission/slot calling. That is not what we want. We want the signals to run, just not on the same call chain as the resize event. REPOSITORY

D6624: do not crash qaccessible by causing a resize in a resize event

sitter added a comment. FWIW, this is a bit of workaround. Not having kcharselect crash for just about every search is well worth it though. Also, I am not sure I particularly like the qtimer code. It does beat having to pass `const char *` method names to `invokeMethod` and turning the

D6624: do not crash qaccessible by causing a resize in a resize event

sitter created this revision. Restricted Application added a project: Frameworks. Restricted Application added a subscriber: Frameworks. REVISION SUMMARY When enabling accessibility qaccessible will automatically add a11y support constructs to core qt types such as qtableview. Unfortunately

D6604: add a metainfo.yaml to make ECM a proper framework

sitter added a comment. Good point on trying it locally. So, as one could expect this adds ECM as a product F3808791: Screenshot_20170711_120142.png Unfortunately given we have no actual documentation (outside the cmake documentation)

D6604: add a metainfo.yaml to make ECM a proper framework

sitter added a comment. related to https://phabricator.kde.org/D6603 @ochurlaud I hope this will not break api.kde, given ECM hasn't had a metainfo.yaml previously it seems to have some sort of special arrangement? REPOSITORY R240 Extra CMake Modules REVISION DETAIL

D6604: add a metainfo.yaml to make ECM a proper framework

sitter created this revision. Restricted Application added projects: Frameworks, Build System. Restricted Application added subscribers: Build System, Frameworks. REPOSITORY R240 Extra CMake Modules BRANCH master REVISION DETAIL https://phabricator.kde.org/D6604 AFFECTED FILES

D6558: do not stderr that NoDisplay is set

This revision was automatically updated to reflect the committed changes. Closed by commit R290:48f1ece4a4ce: do not stderr that NoDisplay is set (authored by sitter). REPOSITORY R290 KPackage CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D6558?vs=16313=16439 REVISION DETAIL

D6558: do not stderr that NoDisplay is set

sitter created this revision. Restricted Application added a project: Frameworks. Restricted Application added a subscriber: Frameworks. REVISION SUMMARY KF5PackageMacros turns stderr output into cmake level warnings. setting nodisplay is perfectly reasonable and doesn't warrant a warning.

Re: Elisa is in kdereview

On Wed, Jun 21, 2017 at 11:15 PM, Matthieu Gallien wrote: > Hello, > On mercredi 21 juin 2017 23:01:23 CEST Albert Astals Cid wrote: >> El divendres, 16 de juny de 2017, a les 22:44:03 CEST, Matthieu Gallien va >> >> escriure: >> > Hello, >> > >> > Elisa is now in

Re: extra-cmake-modules in kdesupport?

On Sat, Jun 3, 2017 at 11:32 AM, David Faure <fa...@kde.org> wrote: > On mardi 30 mai 2017 16:18:42 CEST Aleix Pol wrote: >> On Tue, May 30, 2017 at 4:10 PM, Luigi Toscano <luigi.tosc...@tiscali.it> > wrote: >> > On Tuesday, 30 May 2017 16:06:56 CEST Harald Sitt

Re: projects api alpha

stable now On Wed, May 24, 2017 at 5:57 PM, Harald Sitter <sit...@kde.org> wrote: > I finally got annoyed with the obscenely large xml file we had for > projects and wrote a RESTful api to replace it. > > https://projects.kde.org/api/ > https://cgit.kde.org/sysadmin/projec

extra-cmake-modules in kdesupport?

Is there a reason ECM's project is placed in kdesupport rather than frameworks? https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects/kdesupport/extra-cmake-modules Seems a bit fishy at best and practically means that if ECM ever were to get translations it wouldn't inherit the

projects api alpha

I finally got annoyed with the obscenely large xml file we had for projects and wrote a RESTful api to replace it. https://projects.kde.org/api/ https://cgit.kde.org/sysadmin/projects-api.git/ Usage example https://cgit.kde.org/releaseme.git/commit?id=d5ae8f9b3a56b0521e84b6e5955faecb6e6099c0

Re: Requiem for Pure C++ plasmoid, and QML plugin... again :S

You may wish to note that plasma-devel is a more on-point mailing list for plasma widget questions. Also, you can model xml using qml exclusively [0]. Should you opt not to, what you need to do is write one plugin, not two. If you want to go the custom plugin route have a look at [1] for example.

D5741: Fix test when compiling from a tarball

sitter accepted this revision. This revision is now accepted and ready to land. REPOSITORY R240 Extra CMake Modules BRANCH master REVISION DETAIL https://phabricator.kde.org/D5741 To: apol, #frameworks, joselema, sitter Cc: #build_system

D5557: fix basename handling of po files

This revision was automatically updated to reflect the committed changes. Closed by commit R249:7bce4e812836: fix basename handling of po files (authored by sitter). REPOSITORY R249 KI18n CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D5557?vs=13728=13770 REVISION DETAIL

D5557: fix basename handling of po files

sitter created this revision. Restricted Application added a project: Frameworks. Restricted Application added a subscriber: Frameworks. REVISION SUMMARY get_filename_component(... ... NAME_WE) gets the name without the *longest* extension. in case of 'org.kde.plasma.kittens.po' that would

D5534: Fix ki18n bootstrapping

sitter accepted this revision. This revision is now accepted and ready to land. REPOSITORY R249 KI18n BRANCH master REVISION DETAIL https://phabricator.kde.org/D5534 To: apol, #frameworks, sitter

D5525: adapt to fetchpo changes and use vars for target directories to dry code

This revision was automatically updated to reflect the committed changes. Closed by commit R240:77623d19b627: adapt to fetchpo changes and use vars for target directories to dry code (authored by sitter). REPOSITORY R240 Extra CMake Modules CHANGES SINCE LAST UPDATE

D5525: adapt to fetchpo changes and use vars for target directories to dry code

sitter created this revision. Restricted Application added projects: Frameworks, Build System. Restricted Application added subscribers: Build System, Frameworks. REVISION SUMMARY - fetchpo now expects the output dirs as named arguments - new argument for poqm directories where releaseme will

D5167: Move .po and .ts files look-up to build-time

sitter accepted this revision. sitter added a comment. This revision is now accepted and ready to land. Note that there's still an ordering problem with the new fetch-translations target now. The {ts,po}files-* targets can run before the fetch-translations target so on first run you may have

D5523: use correct variable for fetch-translations injection

This revision was automatically updated to reflect the committed changes. Closed by commit R240:fe46a935227f: use correct variable for fetch-translations injection (authored by sitter). REPOSITORY R240 Extra CMake Modules CHANGES SINCE LAST UPDATE

D5523: use correct variable for fetch-translations injection

sitter created this revision. Restricted Application added projects: Frameworks, Build System. Restricted Application added subscribers: Build System, Frameworks. REVISION SUMMARY KDE_L10N_AUTO_TRANSLATIONS is the name of the relevant option REPOSITORY R240 Extra CMake Modules BRANCH

Re: KAuth buildability: new CI architecture

On Mon, Apr 17, 2017 at 9:30 AM, Martin Gräßlin wrote: >> Would it be possible to use relative-to-calling-binary paths? > > > Simply put: no. That would require quite some engineering effort especially > considering that distros do have the libexec paths different with some >

Re: KAuth buildability: new CI architecture

Not particularly related to the issue at hand (which is probably polkitqt having meh cmake files), but relocating stuff in general is sper unreliable and I would absolutely advise against it as it can easily screw up test results and builds alike, often in unobvious ways (all it takes is a bit

D5167: Move .po and .ts files look-up to build-time

sitter added inline comments. INLINE COMMENTS > KF5I18NMacros.cmake:136 > +function(ki18n_install_ts_files _lang) > +message(WARNING "KI18N_INSTALL_TS_FILES is deprecated!") > +ki18n_install(${_lang}) Please use `message(AUTHOR_WARNING ...` this warning has only relevance to a

<    4   5   6   7   8   9   10   11   12   13   >