Re: Review Request 120648: Encode the URIs which end up in DTD files

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120648/#review68675 --- These are both RRs for KF5? - René J.V. Bertin On Oct. 18,

Re: Review Request 120648: Encode the URIs which end up in DTD files

On Oct. 18, 2014, 8:50 p.m., René J.V. Bertin wrote: These are both RRs for KF5? Luigi Toscano wrote: Yes, otherwise the repository would have been kdelibs. Do you think it would make sense to backport it? You say that this is for when the path contains spaces, as it happens on

Review Request 121390: make Qt5 part build on Linux again

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121390/ --- Review request for KDE Frameworks, Qt KDE and Yichao Yu. Repository:

Re: Review Request 121390: make Qt5 theme build on Linux again

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121390/ --- (Updated Dec. 8, 2014, 2:38 p.m.) Review request for KDE Frameworks, Qt

Re: Review Request 121390: make Qt5 theme build on Linux again

On Dec. 8, 2014, 3:07 p.m., Martin Gräßlin wrote: this is wrong - please have a look at various frameworks on how to do it properly. In the end it should be: #if HAVE_X11 // x11 specific stuff #endif obviously it also needs a runtime check: if (QX11Info::isPlatformX11())

Re: Review Request 121390: make Qt5 theme build on Linux again

On Dec. 8, 2014, 3:07 p.m., Martin Gräßlin wrote: this is wrong - please have a look at various frameworks on how to do it properly. In the end it should be: #if HAVE_X11 // x11 specific stuff #endif obviously it also needs a runtime check: if (QX11Info::isPlatformX11())

Re: Review Request 121390: make Qt5 theme build on Linux again

On Dec. 8, 2014, 3:07 p.m., Martin Gräßlin wrote: this is wrong - please have a look at various frameworks on how to do it properly. In the end it should be: #if HAVE_X11 // x11 specific stuff #endif obviously it also needs a runtime check: if (QX11Info::isPlatformX11())

Re: Review Request 121390: make Qt5 theme build on Linux again

On Dec. 8, 2014, 3:07 p.m., Martin Gräßlin wrote: this is wrong - please have a look at various frameworks on how to do it properly. In the end it should be: #if HAVE_X11 // x11 specific stuff #endif obviously it also needs a runtime check: if (QX11Info::isPlatformX11())

Re: Review Request 121390: make Qt5 theme build on Linux again

On Dec. 8, 2014, 3:07 p.m., Martin Gräßlin wrote: this is wrong - please have a look at various frameworks on how to do it properly. In the end it should be: #if HAVE_X11 // x11 specific stuff #endif obviously it also needs a runtime check: if (QX11Info::isPlatformX11())

Re: Review Request 121390: make Qt5 theme build on Linux again

On Dec. 8, 2014, 3:07 p.m., Martin Gräßlin wrote: this is wrong - please have a look at various frameworks on how to do it properly. In the end it should be: #if HAVE_X11 // x11 specific stuff #endif obviously it also needs a runtime check: if (QX11Info::isPlatformX11())

Re: Review Request 121390: make Qt5 theme build on Linux again

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121390/ --- (Updated Dec. 8, 2014, 10:59 p.m.) Review request for KDE Frameworks, Qt

Re: OSX/CI: QSP patch ( was KF5 Update Meeting Minutes 2014-w28 )

On Saturday January 03 2015 11:53:48 Andrius da Costa Ribas wrote: Regarding oxygen, we'd probably change it later into breeze. My advice: don't, it's ugly and way too spacious ;) Then again, oxygen5 is, too. Oxygen works fine (Qt fallbacks to ugly win9x when it's not available). Not to

Re: Review Request 122481: Fix use of environ for OS X

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122481/#review75613 --- src/widgets/kurlcompletion.cpp

Re: Review Request 122481: Fix use of environ for OS X

On Feb. 8, 2015, 5:44 p.m., René J.V. Bertin wrote: src/widgets/kurlcompletion.cpp, line 836 https://git.reviewboard.kde.org/r/122481/diff/1/?file=347903#file347903line836 Qt5 has Q_OS_OSX to target OS X rather than a Mac OS (which according to Qt includes iOS). For

Re: Review Request 121390: make Qt5 theme build on Linux again

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121390/ --- (Updated March 1, 2015, 10:02 p.m.) Status -- This change has been

Re: [KDE/Mac] CI for kf5-qt5 is not green anymore

On Saturday May 02 2015 09:42:44 Scarlett Clark wrote: On Saturday, May 02, 2015 10:20:27 AM David Faure wrote: KMainWindow_UnitTest::testDefaultName() Cannot create window: no screens available Yes it is a CI issue. We connect to slaves via SSH and therefore GUI is not available. I am not a

Re: Review Request 123595: Fix KUser test for Mac.

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123595/#review79976 --- I'm not sure, after reading

Re: Review Request 123595: Fix KUser test for Mac.

On May 6, 2015, 6:40 p.m., René J.V. Bertin wrote: I'm not sure, after reading http://pig.made-it.com/uidgid.html also: ``` id nobody uid=4294967294(nobody) gid=4294967294(nobody)

Re: Review Request 124892: bug 342962: kdeclarative plugins should be built as a bundle plugin and not a shared library

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124892/#review84338 --- When built as SHARED as in the current code,

Re: [KDE/Mac] Question about goal of Windows/Mac frameworks

On Thursday October 22 2015 18:48:30 Marko Käning wrote: > have you followed the discussion with Qt's developers regarding the QSP patch > [1]? > If not, I advise you to do a little reading there! > Qt won’t ever support such an approach, i.e. one would have to patch it, if > KDE itself doesn’t

Re: [KDE/Mac] Question about goal of Windows/Mac frameworks

On Thursday October 22 2015 22:05:59 Marko Käning wrote: > > https://bugreports.qt.io/browse/QTBUG-44473?focusedCommentId=272971=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-272971) > > Because the proposal supports environment variables too, I guess this > > would

Re: [KDE/Mac] Question about goal of Windows/Mac frameworks

On Wednesday October 21 2015 13:08:46 Dominik Haumann wrote: > In Windows, such a package manager does not exist. KDE tried to create > such a package manager through the emerge/KDE Windows installer, but > this is non-standard [on Windows] and simply not what users want. That's not entirely

Re: [KDE/Mac] Question to experienced Mac devs about goal of Windows/Mac frameworks

On Wednesday October 21 2015 11:30:46 Jaroslaw Staniek wrote: >- Looking at competition is always good. Do these MS Office/Adobe apps use >dbus? I don't think so, and my suggestion to look at commercial software suites was unrelated to the use of dbus. It was made with deployment in mind,

Re: [KDE/Mac] Question about goal of Windows/Mac frameworks

On Wednesday October 21 2015 22:12:00 Christoph Cullmann wrote: > Maybe, but actually, even with the most dumb application bundle I have > created ATM > all stuff together is around 50 MB compressed and installed 125 MB. > > This includes a more or less complete Qt (with webkit, some debug

Re: [mostly OS X]: KDEHOME vs. ~/.kde best practices, *rc files and related questions

On Sunday November 08 2015 21:58:21 David Faure wrote: >Not really. I do exactly that to run KF5 apps in a KDE4 desktop here. Et te, Brutus? :) >It's just a matter of writing your export statements in a file that you source >before running a kf5 app (from a terminal). The sourcing of the env

kpackage: reasons not to use ecm_mark_nongui_executable?

Hi, I've just made the MacPorts packaging for the Package framework, and noticed that both the kpackagetool and the autotests are not defined "ecm_mark_nongui_executable". That means they're build as app bundles on OS X, which is counterproductive (and causes "make test" to fail). Is there a

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

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

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 >>

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 ... >

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

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

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. ___

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

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

Re: kpackage: reasons not to use ecm_mark_nongui_executable?

Alex Merry wrote: > I would expect that they should be nongui. We've realised that there are > some cases where we want to be marked GUI on windows and not on OS X, > but I doubt that's the case for KPackage. Do you know if applications marked non-gui initialise the windowserver connection on

[mostly OS X]: KDEHOME vs. ~/.kde best practices, *rc files and related questions

Hi, I have some questions related to where KF5 expects its configuration files and other local stuff, how KF5 and KDE4 applications cohabit (or not) in that aspect, etc. Some of these are inspired by the fact that I have noticed several weird issues on my Kubuntu KDE4.14 desktop after having

Re: [mostly OS X]: KDEHOME vs. ~/.kde best practices, *rc files and related questions

David Faure wrote: Thanks, David, > It will be for sure, since KF5 doesn't use ~/.kde at all anymore. > It uses what QSP returns for GenericConfigLocation. > > So on Linux it uses ~/.config (or $XDG_CONFIG_HOME if set) > and ~/.local (or $XDG_DATA_HOME if set). I suppose it's left to

Re: [mostly OS X]: KDEHOME vs. ~/.kde best practices, *rc files and related questions

On Sunday November 08 2015 18:25:25 David Faure wrote: > Don't even think about it. What, I'm not allowed to scare myself? :) > But you can of course export a different value for > XDG_CONFIG_HOME or XDG_DATA_HOME. A bit difficult to do that only for KF5 applications, eh? Except maybe through

KGlobalAccel on ~Linux?

Hi, KDE4's kglobalaccel works just fine on Mac OS X; is there a reason why the KF5 wouldn't? R. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

kxmlgui: klanguageoverridesrc format

Hi, KXmlGui currently uses QSettings in NativeFormat to write klanguageoverridesrc . On OS X, that means it will become a binary XML file called klanguageoverridesrc.plist, which I personally find undesirable. I think that the effect is even larger on MS Windows. On Linux, NativeFormat and

Re: KGlobalAccel on ~Linux?

Martin Graesslin wrote: > Well it could also mean that kglobalaccel5 directly crashes because it doesn't > have a backend and we just don't see the backtrace due to missing drkonqi. Running under a debugger should show if it crashes, before kcrash gets a chance to call drkonqi, no? Drkonqi is

Re: KGlobalAccel on ~Linux?

Martin Graesslin wrote: > because nobody ported it to Qt's new native event filter. I would love to see > this enabled again for the non Linux platforms. Hmm, I see. That's something I should look into then, if I find its functionality is indeed lacking. I know kglobalaccel4 works and gets

Re: kxmlgui: klanguageoverridesrc format

On Friday November 13 2015 22:10:07 David Faure wrote: > Kévin wrote this code in ed10e3fd484570, the main point was to switch from > KConfig to QSettings > for this particular setting. NativeFormat is clearly just an accident there, > feel free to change it. I hope that meant OK to commit -

[OS X] should kauth-policy-gen be an app bundle?

Hi, I'm not really familiar with the role of kauth-policy-gen (or the one it would play on OS X), or how it's supposed to be called. Is there a reason to build it as an app bundle on OS X, or should it rather be a regular executable as I'd expect? R.

Re: KGlobalAccel on ~Linux?

David Faure wrote: > Right. Add /opt/local/share to XDG_DATA_DIRS before starting the DBus daemon, > otherwise the dbus service cannot be autostarted. BTW, I presume this DBus issue has nothing to do with QStandardPaths, but should /opt/local/share show up only in GenericDataLocation or also

Re: Review Request 126078: [OS X] modernising the KIdleTime plugin (WIP!)

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126078/ --- (Updated Nov. 16, 2015, 4:42 p.m.) Review request for KDE Software on

Review Request 126086: kauth-policy-gen should not be an app bundle on OS X

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126086/ --- Review request for KDE Software on Mac OS X and KDE Frameworks.

Re: Review Request 126078: [OS X] modernising the KIdleTime plugin (WIP!)

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126078/#review88418 --- Here's a debugging trace after hitting a breakpoint set on

Re: Review Request 126078: [OS X] modernising the KIdleTime plugin (WIP!)

On Monday November 16 2015 12:29:49 René J.V. Bertin wrote: > If that's the intended behaviour, why does the KIdleTime example work on > Linux, without "restarting" `catchNextResumeEvent`?? Sorry for the rapid fire of growing messages - that comes with asking questions through RRs ... I

Re: Review Request 126078: [OS X] modernising the KIdleTime plugin (WIP!)

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126078/ --- (Updated Nov. 16, 2015, 11:03 p.m.) Review request for KDE Software on

KIdleTime : provide a settable resolution for the polling backends?

Hi, Working on modernising the OS X plugin for KIdleTime, I realised that there is no mechanism foreseen to set the frequency at which the current system idle time should be sampled on those platforms that need to use a polling approach (OS X, MS Windows and apparently also XScreenSaver). The

Re: Review Request 126078: [OS X] modernising the KIdleTime plugin (WIP!)

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126078/ --- (Updated Nov. 16, 2015, 11:15 p.m.) Review request for KDE Software on

Re: Review Request 126086: kauth-policy-gen should not be an app bundle on OS X

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126086/ --- (Updated Nov. 16, 2015, 10:15 p.m.) Review request for KDE Software on

Re: KIdleTime : provide a settable resolution for the polling backends?

Aleix Pol wrote: > I guess it's because it shouldn't poll necessarily, but get a > notification whenever the OS considers appropriate. Polling is > considered a bad practice in general. I'd agree, but not all OSes provide other mechanisms, in which case polling is the only remaining option.

Re: Review Request 126069: [OS X] better integration of the cross-platform wallet runtime

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126069/ --- (Updated Nov. 16, 2015, 12:59 p.m.) Review request for KDE Software on

Re: [OS X] should kauth-policy-gen be an app bundle?

On Monday November 16 2015 00:15:10 Aleix Pol wrote: >Please make a RR, if you had done we I would have reviewed it instead >of replying to this e-mail. Because reading the RR alert, clicking on the link, looking over it, clicking on the "Add comment" link and answering is faster and more

Re: Review Request 126069: [OS X] better integration of the cross-platform wallet runtime

> On Nov. 15, 2015, 12:33 a.m., Aleix Pol Gonzalez wrote: > > src/runtime/kwallet-query/src/CMakeLists.txt, line 20 > > > > > > Why only for APPLE? > > René J.V. Bertin wrote: > Mostly because I didn't want

Re: Review Request 126078: [OS X] modernising the KIdleTime plugin (WIP!)

On Nov. 16, 2015, 12:19 a.m., René J.V. Bertin wrote: > > In fact, I'm quite sure that as is it already is broken without the #define Hmm? What do you think I broke that wasn't broken before (again, apart from the bare idle time detection, the original code doesn't work for me). Anyway, I'm

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

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: KIdleTime : to poll not or provide a settable resolution for the polling backends?

René J. V. Bertin wrote: > As to MacPoller: I'll see whether I subclass WidgetBasedPoller or whether it's > just as efficient to copy/paste the relevant code (if I'd be overriding too > many methods, which might be the case here). Seems I'll be doing copy/paste, because when I subclass

Re: KIdleTime : to poll not or provide a settable resolution for the polling backends?

Martin Graesslin wrote: Sorry, long reply, too many arguments. > Don't poll. Never ever, don't poll. That's the opposite of what an application wants to do. As I said elsewhere, while I agree on the principle I don't think that should be dogma. It depends on the requirements of the

Re: KIdleTime: early and/or failing/rejected timeout detection?

Martin Graesslin wrote: > I don't really understand. How can it signal too early? I was wrong about the MS Windows implementation, but from WidgetBasedPoller: Q_FOREACH(int timeOut, m_timeouts) { if ( ( timeOut - idle < 300 && timeOut >= idle ) || ( idle - timeOut < 300 && idle >

KIdleTime: early and/or failing/rejected timeout detection?

KIdleTime really seems to have captured my attention - it's after all very closely related to "problems" I've had to solve more than a few times in a previous life. Currently, the MS Windows and OS X backends have 2 issues with detecting & signalling idle timeouts, aside from the fact they

Re: KIdleTime: early and/or failing/rejected timeout detection?

Martin Graesslin wrote: > NO POLLING! > > If you cannot do that on OSX, I really think it's better to not provide it. If > you think it's unfair that there is a backend for X11 which performs polling, > then I'm going to delete the XScreenSaver based one. I'm not adding code that polls, I'm

Re: KIdleTime : to poll not or provide a settable resolution for the polling backends?

Another thing I should have realised: It is not currently feasible with Qt to detect "global" events that are not destined to "ourselves" (see http://stackoverflow.com/questions/19229777/how-to-detect-global-mouse-button-events and

KService autotests and tests on OS X

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) 2) I discovered, some time after having attempted to run these, that a large

Re: [OS X] "unknown type name 'KARCHIVE_DEPRECATED'" building kdoctools

Alex Merry wrote: > Looks like your include path is wrong. /opt/local/include/KF5/KArchive > should be in the include path (before wherever wherever your kdelibs4 > headers are). I suppose you're right, but AFAIK I don't do anything either to alter the install location (relative to /opt/local)

Re: [OS X] "unknown type name 'KARCHIVE_DEPRECATED'" building kdoctools

Alex Merry wrote: > Well, if we'd done it for kdelibs4 as well, you wouldn't have this issue > - if you had to add -I/opt/local/include/kdelibs in order to find any > kdelibs headers, none would be found by mistake. Fair enough, but you didn't :) FWIW (and because there are some on here who

Re: [OS X] "unknown type name 'KARCHIVE_DEPRECATED'" building kdoctools

René J. V. Bertin wrote: > Alex Merry wrote: > >> Looks like your include path is wrong. /opt/local/include/KF5/KArchive >> should be in the include path (before wherever wherever your kdelibs4 >> headers are). In fact: cd /opt/local/var/macports/build/_opt_local_site-

Re: [OS X] avoiding kdelibs4 headers? ("unknown type name 'KARCHIVE_DEPRECATED'" building kdoctools)

Alex Merry wrote: > Well, if we'd done it for kdelibs4 as well, you wouldn't have this issue > - if you had to add -I/opt/local/include/kdelibs in order to find any > kdelibs headers, none would be found by mistake. Before I find myself patching who knows how many KF5 files: is there a

Re: [OS X] avoiding kdelibs4 headers? ("unknown type name 'KARCHIVE_DEPRECATED'" building kdoctools)

René J. V. Bertin wrote: > Before I find myself patching who knows how many KF5 files: is there a > provision in KDELibs4 to install its headers in a place where they shouldn't > clash with KF5's headers? (apologies for asking a bit too quickly): It seems that configuring

[OS X] "unknown type name 'KARCHIVE_DEPRECATED'" building kdoctools

Hi, Building KF5/kdoctools 5.15.0 on OS X, I run into 2 issues: - the #include statement finds the corresponding header from KDELibs4 - after changing the statement into #include (which I think it should be anyway?), I get the error In file included from

Fwd: KF5 plugins and PLUGIN_INSTALL_DIR vs QT_PLUGIN_INSTALL_DIR

Sorry for the cross-posting, I'm really hoping for a fast resolution of this question... --- Hi, I came across an old message and commit from David Faure (https://mail.kde.org/pipermail/kde-buildsystem/2012-September/008851.html) that seems related to an issue I'm

kf5 frameworks autotest alters KDE4 desktop workspace settings?!

Hi, I've been building KF5 frameworks to install under /opt/local on a KUbuntu 14.04 host running a KDE4 desktop, using the same packaging scripts I'm developing for Mac OS X (MacPorts; evidently with some modifications for using them on Linux). I'm not patching the source code except where

Re: [KDE/Mac] [OS X] adding a link module to all KF5 targets

On Thursday October 15 2015 09:14:42 Christoph Cullmann wrote: >> KDE and its Frameworks and KF5 successors EMBRACE file-sharing between >> applications, utilities and libraries. >Actually, I here already disagree. Hmmm? >At least some KDE application developers like me or the Krita team want

Re: [KDE/Mac] [OS X] adding a link module to all KF5 targets

FYI: with a bit of help from a friendly Qt developer, I've now been able to come up with a QSP patch that includes the necessary "logic" to flip the switch at link time using either QT += qsp_xdg (qmake) or find_package(Qt5QspXDG) target_link_libraries(... Qt5::QspXDG ...) (cmake) and

Re: [KDE/Mac] [OS X] adding a link module to all KF5 targets

On Wednesday October 14 2015 22:12:31 Christoph Cullmann wrote: > isn't this really all going in the completely wrong direction? No. Pragmatism may not be the best but is never the wrong direction. Skip back and note how I accepted the idea of local patching of toplevel CMake files to build KF5

Re: [KDE/Mac] Question about goal of Windows/Mac frameworks

Please, hold this poll in the user communities (as far as they exist), and not only among the developers. That is of course if you're doing all this with the requirements of the people who'll end up using your stuff foremost in mind. I think you'll find that many if not most Mac users don't

Re: [KDE/Mac] Question about goal of Windows/Mac frameworks

On Tuesday October 20 2015 13:29:21 Jeremy Whiting wrote: >applications. I can also see the same power users recommending >individual applications to their relatives (moms, grandmothers, etc.) >using single application installers as you described. "Here mom, >download this one bundle to install

Re: [KDE/Mac] Question to experienced Mac devs about goal of Windows/Mac frameworks

On Wednesday October 21 2015 11:30:46 Jaroslaw Staniek wrote: > ​I don't think separating community this way is acceptable. Or categorising > people. There are smart people that can have multiple hats. > Even for example, less advanced OS X users have right to demand native UI > styling on the

Re: [KDE/Mac] [OS X] adding a link module to all KF5 targets

On Wednesday October 14 2015 23:46:14 Christoph Cullmann wrote: > you are aware that with this we introduce just a extra platform we will get > bugs > for? We then not have just Mac/Qt but also Mac/Qt-X11 which is not even > officially > supported by Qt itself? But what gave you the idea that

Re: [KDE/Mac] Question to experienced Mac devs about goal of Windows/Mac frameworks

T,FTFY :) Seriously, how many people on here are Mac developers with significant experience targeting native OS X APIs, and how many have significant experience using Macs as Unix-based workstations with a true, integrated desktop? Think of significant as "going back to before the last few,

Re: Review Request 125614: Enable normal rpath handling on Mac

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125614/#review86752 --- There is an issue with Qt 5.5.0's configure script,

Re: Review Request 125614: Enable normal rpath handling on Mac

> On Oct. 12, 2015, 10:48 p.m., René J.V. Bertin wrote: > > There is an issue with Qt 5.5.0's configure script, currently. From what I > > understand, the `-rpath` configure option works as intended, and gives > > relocatable framework bundles that are intended to be embedded in dependent > >

Re: Review Request 125614: Enable normal rpath handling on Mac

> On Oct. 12, 2015, 10:48 p.m., René J.V. Bertin wrote: > > There is an issue with Qt 5.5.0's configure script, currently. From what I > > understand, the `-rpath` configure option works as intended, and gives > > relocatable framework bundles that are intended to be embedded in dependent > >

Re: Review Request 125614: Enable normal rpath handling on Mac

> On Oct. 12, 2015, 10:48 p.m., René J.V. Bertin wrote: > > There is an issue with Qt 5.5.0's configure script, currently. From what I > > understand, the `-rpath` configure option works as intended, and gives > > relocatable framework bundles that are intended to be embedded in dependent > >

Re: Review Request 125614: Enable normal rpath handling on Mac

> On Oct. 12, 2015, 10:48 p.m., René J.V. Bertin wrote: > > There is an issue with Qt 5.5.0's configure script, currently. From what I > > understand, the `-rpath` configure option works as intended, and gives > > relocatable framework bundles that are intended to be embedded in dependent > >

Re: [KDE/Mac] [OS X] adding a link module to all KF5 targets

Jeremy Whiting wrote: > That does sound like a bit more interesting question. Browsing through Bump ... I think I'll try a simpler approach, where I'd have to patch each toplevel CMake file (including of the frameworks themselves, to be exhaustive) to add a module in the find_package(Qt5

Re: Review Request 125614: Enable normal rpath handling on Mac

> On Oct. 12, 2015, 10:48 p.m., René J.V. Bertin wrote: > > There is an issue with Qt 5.5.0's configure script, currently. From what I > > understand, the `-rpath` configure option works as intended, and gives > > relocatable framework bundles that are intended to be embedded in dependent > >

Re: Review Request 126078: [OS X] modernising the KIdleTime plugin (WIP!)

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126078/ --- (Updated Nov. 18, 2015, 5:35 p.m.) Status -- This change has been

Re: Review Request 126078: [OS X] modernising the KIdleTime plugin (WIP!)

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126078/ --- (Updated Nov. 18, 2015, 5:35 p.m.) Review request for KDE Software on

Re: Review Request 126078: [OS X] modernising the KIdleTime plugin (WIP!)

On Wednesday November 18 2015 15:01:59 Martin Gräßlin wrote: > idiotic If we're starting to call names arguing indeed becomes pointless as the apparent lack of actual reading my arguments already suggested. It leaves me with no other choice but to discard the RR and put up a mirror in place.

Review Request 126069: [OS X] better integration of the cross-platform wallet runtime

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126069/ --- Review request for KDE Software on Mac OS X and KDE Frameworks.

Re: Review Request 126069: [OS X] better integration of the cross-platform wallet runtime

> On Nov. 15, 2015, 12:33 a.m., Aleix Pol Gonzalez wrote: > > src/runtime/kwallet-query/src/CMakeLists.txt, line 20 > > > > > > Why only for APPLE? Mostly because I didn't want to pretend to know the

Re: Review Request 124916: also make kwindowsystem a module rather than a shared lib

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124916/#review84329 --- Margin note: While it's great to see that some developers are

Re: [KDE/Mac] [OS X] adding a link module to all KF5 targets

On Tuesday September 29 2015 09:45:02 David Faure wrote: Hi, I appreciate your continued interest (and not having to send a 'bump' message :)) >You don't *really* need XDG on OSX. You need files to be found, it's just >easier to do that by coying what we do on Linux/BSD ;) Sure. But if it

Re: [KDE/Mac] [OS X] adding a link module to all KF5 targets

On Tuesday September 29 2015 09:45:02 David Faure wrote: >> > One thing I like about this, as a side effect, is that my unittests which >> > need to >> > have control over *global* QSP paths (which I do by setting XDG_DATA_DIRS >> > but I have to skip such unittests on OSX/Windows) could then be

  1   2   3   4   5   6   7   8   9   10   >