Review Request 126039: When configfile is loaded from resource, do not issue file not found error

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126039/ --- Review request for KDE Frameworks and Jeremy Whiting. Repository: knewstu

Review Request 126038: Add protocol info to KIO plugin metadata

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126038/ --- Review request for KDE Frameworks. Repository: kio Description ---

Re: Frameworks API documentation broken

On 2015-11-11 14:15, Allen Winter wrote: On Wednesday, November 11, 2015 08:13:17 AM Allen Winter wrote: On Wednesday, November 11, 2015 11:33:17 AM Martin Graesslin wrote: > Hi all, > > I just wanted to raise awareness of the fact that the Frameworks API > documentation on api.kde.org is comple

[kapidox] src: Make kgenframeworksapidox more robust.

Git commit 13a58615d0d49709345cc4dca8eef41b991dd2a2 by Alex Merry. Committed on 11/11/2015 at 23:51. Pushed by alexmerry into branch 'master'. Make kgenframeworksapidox more robust. It should be harder to break it with unusual or broken metainfo.yaml files now. CCMAIL: allen.d.win...@gmail.com C

Re: [Development] QStandardPaths::writableLocation() on OSX in test mode

On Wednesday November 11 2015 20:37:36 Petroules Jake wrote: > What we SHOULD have in Qt is something similar to NSSearchPathDomainMask so > we could have a little more fine grained control. Maybe a user WANTS to write > to locations in the local domain instead of the user domain (and in some >

Re: [Development] QStandardPaths::writableLocation() on OSX in test mode

On Nov 11, 2015, at 12:21 PM, David Faure mailto:fa...@kde.org>> wrote: On Wednesday 11 November 2015 19:09:58 Petroules Jake wrote: Feel free to do whatever you like for test mode but do not change the existing writable paths. Jake, I would like to understand why you say that. As the QSP auth

Re: [Development] QStandardPaths::writableLocation() on OSX in test mode

On Wednesday 11 November 2015 19:09:58 Petroules Jake wrote: > Feel free to do whatever you like for test mode but do not change the > existing writable paths. Jake, I would like to understand why you say that. As the QSP author and maintainer, I am 100% sure that the value of writableLocation(x

Re: Review Request 125951: [calendar] Move the plugins handling to a separate class

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125951/ --- (Updated Nov. 11, 2015, 8:54 p.m.) Review request for KDE Frameworks and

Re: Review Request 125936: Update KProtocolManager after configuration change.

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125936/ --- (Updated Nov. 11, 2015, 7:30 p.m.) Status -- This change has been ma

Re: [Development] QStandardPaths::writableLocation() on OSX in test mode

On Nov 11, 2015, at 8:20 AM, René J.V. Bertin mailto:rjvber...@gmail.com>> wrote: On Wednesday November 11 2015 16:03:31 Petroules Jake wrote: I don't understand, what do you mean with "there is only one location"? I mean the API returns a single value, not a list. However, READable locations

Re: [Development] QStandardPaths::writableLocation() on OSX in test mode

On Wednesday November 11 2015 19:07:17 David Faure wrote: > Yes, and the value returned by writableLocation() is supposed to be > user-specific > (something under $HOME) rather than system-wide. Agreed. > > So /Applications should be in QSP::standardLocations(ApplicationsLocation) > but QSP::w

Re: [Development] QStandardPaths::writableLocation() on OSX in test mode

On Wednesday 11 November 2015 16:03:31 Petroules Jake wrote: > I mean the API returns a single value, not a list. Yes, and the value returned by writableLocation() is supposed to be user-specific (something under $HOME) rather than system-wide. So /Applications should be in QSP::standardLocatio

Re: [Development] QStandardPaths::writableLocation() on OSX in test mode

On Nov 11, 2015, at 7:13 AM, René J.V. Bertin mailto:rjvber...@gmail.com>> wrote: On Wednesday November 11 2015 15:52:33 David Faure wrote: Cross-posting on Qt's development ML because it seems more than relevant there. To put things in context: this discussion on kde-frameworks-devel was star

Re: Frameworks API documentation broken

On Wednesday, November 11, 2015 11:33:17 AM Martin Graesslin wrote: > Hi all, > > I just wanted to raise awareness of the fact that the Frameworks API > documentation on api.kde.org is completely broken. Currently one only gets > error 404 when clicking on the framework links and also in the sea

Re: [Development] QStandardPaths::writableLocation() on OSX in test mode

On Nov 11, 2015, at 7:53 AM, René J.V. Bertin mailto:rjvber...@gmail.com>> wrote: On Wednesday November 11 2015 15:32:20 Petroules Jake wrote: No, there is only one location so it must remain /Applications as expected by anyone on the OS X platform. I don't understand, what do you mean with "

Re: KService autotests and tests on OS X

On Wednesday November 11 2015 15:49:23 David Faure wrote: > Do you also install desktop files for apps in there? Why not. That's not the > issue anyway. I have only been installing frameworks until now, so the answer is "I don't know". If .desktop files are installed to ApplicationsLocation by

Re: [Development] QStandardPaths::writableLocation() on OSX in test mode

On Wednesday November 11 2015 16:03:31 Petroules Jake wrote: >I don't understand, what do you mean with "there is only one location"? > >I mean the API returns a single value, not a list. However, READable locations >will return a list containing both $HOME/Applications and /Applications Ah. I h

Re: KService autotests and tests on OS X

On Wednesday November 11 2015 15:49:23 David Faure wrote: >> Related question: is there interplay between QSP::ApplicationsLocation and >> the CMake BUNDLE_INSTALL_DIR variable? Following MacPorts convention I'm >> installing pure Qt5 app bundles into /Applications/MacPorts/Qt5, KDE4 app >> bun

Re: [Development] QStandardPaths::writableLocation() on OSX in test mode

On Wednesday November 11 2015 15:32:20 Petroules Jake wrote: >No, there is only one location so it must remain /Applications as expected by >anyone on the OS X platform. I don't understand, what do you mean with "there is only one location"? It is also expected that regular users do not have wr

Re: QStandardPaths::writableLocation() on OSX in test mode

On Wednesday November 11 2015 15:52:33 David Faure wrote: Cross-posting on Qt's development ML because it seems more than relevant there. To put things in context: this discussion on kde-frameworks-devel was started because an autotest from KService deleted a good chunk from my /Applications di

Re: KService autotests and tests on OS X

I'll make and upload a list of all QSP locations on OS X, native and in XDG mode, regular and in test mode, for verification purposes. The results of that can go into a bug report and code review for QSP (and my own QSP patch). R. ___ Kde-frameworks-d

QStandardPaths::writableLocation() on OSX in test mode

On Wednesday 11 November 2015 15:45:49 René J.V. Bertin wrote: > On Wednesday November 11 2015 14:49:57 David Faure wrote: > > > qstandardpaths_mac.mm says > > QString QStandardPaths::writableLocation(StandardLocation type) > > { > > if (isTestModeEnabled()) { > > const QString qttestD

Re: KService autotests and tests on OS X

On Wednesday 11 November 2015 15:42:37 René J.V. Bertin wrote: > > I had to patch qtpaths to test this easily without digging through source > code: it indeed returns just /Applications . *writableLocation* returns /Applications ? How is that possible? Are you 100% sure you're talking about QS

Re: kf5 frameworks autotest alters KDE4 desktop workspace settings?!

On Wednesday November 11 2015 14:49:57 David Faure wrote: > qstandardpaths_mac.mm says > QString QStandardPaths::writableLocation(StandardLocation type) > { > if (isTestModeEnabled()) { > const QString qttestDir = QDir::homePath() + > QLatin1String("/.qttest"); > QString path;

Re: KService autotests and tests on OS X

On Wednesday November 11 2015 14:47:03 David Faure wrote: > > 2) I discovered, some time after having attempted to run these, that a > > large number of the app bundles under /Applications HAD GONE MISSING. > > Oops!?! That's a diluted version of my own reaction, yesterday at about 23h ... > k

Re: Frameworks API documentation broken

On Wednesday, November 11, 2015 08:13:17 AM Allen Winter wrote: > On Wednesday, November 11, 2015 11:33:17 AM Martin Graesslin wrote: > > Hi all, > > > > I just wanted to raise awareness of the fact that the Frameworks API > > documentation on api.kde.org is completely broken. Currently one only

Re: kf5 frameworks autotest alters KDE4 desktop workspace settings?!

On Wednesday 11 November 2015 13:44:01 René J. V. Bertin wrote: > Alex Merry wrote: > > > The autotests are supposed to use a special magic test directory for > > configuration and preferences (see > > http://doc.qt.io/qt-5/qstandardpaths.html#setTestModeEnabled). So they > > shouldn't be writing

Re: KService autotests and tests on OS X

On Wednesday 11 November 2015 00:24:45 René J.V. Bertin wrote: > Hi, > > Are the autotests and tests of the KService framework supposed to run on OS > X? I tried them, and > > 1) most simply hang after printing an error about a missing application menu > (I no longer have the exact message) me

Review Request 126028: Add support for desktopFileName to NETWinInfo

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126028/ --- Review request for KDE Frameworks, kwin and David Faure. Repository: kwin

Re: kf5 frameworks autotest alters KDE4 desktop workspace settings?!

Alex Merry wrote: > The autotests are supposed to use a special magic test directory for > configuration and preferences (see > http://doc.qt.io/qt-5/qstandardpaths.html#setTestModeEnabled). So they > shouldn't be writing anywhere outside that. If they are, it's a bug > (either in the autotests or

Re: kpackage: reasons not to use ecm_mark_nongui_executable?

Aleix Pol wrote: > That's what the macro does, nothing more: > set_target_properties(${_target} >PROPERTIES >WIN32_EXECUTABLE FALSE >MACOSX_BUNDLE FALSE > ) > Right ... I guess I coul

Re: Review Request 125936: Update KProtocolManager after configuration change.

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125936/#review88251 --- Ship it! OK, that explains it. I was assuming this process wo

Re: Review Request 125936: Update KProtocolManager after configuration change.

> On Nov. 6, 2015, 8:02 a.m., David Faure wrote: > > src/kcms/kio/cache.cpp, line 91 > > > > > > Isn't this done by the call to updateRunningIOSlaves just below, which > > sends the DBus signal "reparseSlaveConfi

Re: Review Request 125936: Update KProtocolManager after configuration change.

> On Nov. 6, 2015, 8:02 a.m., David Faure wrote: > > src/kcms/kio/cache.cpp, line 91 > > > > > > Isn't this done by the call to updateRunningIOSlaves just below, which > > sends the DBus signal "reparseSlaveConfi

Re: Private Qml pugin for Baloo

The code is already in Baloo, under the namespace org.kde.baloo.experimental. It is being used only by KInfoCenter right now. The idea is that it'll not be used in anything critical until the API is stabilized. I don't see the need for API changes in the foreseeable future. So maybe we can move it

Frameworks API documentation broken

Hi all, I just wanted to raise awareness of the fact that the Frameworks API documentation on api.kde.org is completely broken. Currently one only gets error 404 when clicking on the framework links and also in the search I cannot find e.g. the frameworks variant of KAboutData. Cheers Martin

Re: Build and test failures with Qt 5.6 and Qt 5.3

On Wednesday, November 11, 2015 10:22:13 AM CET Jan Kundrát wrote: > On Tuesday, 10 November 2015 08:34:02 CET, Martin Graesslin wrote: > > Yes, most tests don't require a WM. Especially the Net* tests > > simulate being a > > window manager. Only the KWindow* tests need a window manager. > > Inte

Re: Build and test failures with Qt 5.6 and Qt 5.3

On Tuesday, 10 November 2015 08:34:02 CET, Martin Graesslin wrote: Yes, most tests don't require a WM. Especially the Net* tests simulate being a window manager. Only the KWindow* tests need a window manager. Interesting; it was a Heisenbug, apparently. I cannot reproduce it anymore, but I've