Re: Review Request 126161: OS X housekeeping

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126161/ --- (Updated June 18, 2016, 11 a.m.) Review request for KDE Software on Mac

Re: Review Request 128202: Fix problem with install prefix & application bundles

> On June 18, 2016, 11:17 a.m., René J.V. Bertin wrote: > > AFAIK emerge is not an OS X utility, but something ported from elsewhere. > > Does it use `-DBUNDLE_INSTALL_DIR` and if not, why? > > > > A few remarks re: kded5. AFAICT this is one of those things that should > > *not* be installed

Re: Review Request 126170: [OS X] make kded5 an agent, and build it as a regular application instead of an app bundle

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126170/ --- (Updated June 18, 2016, 4:06 a.m.) Status -- This change has been

Re: Review Request 128202: Fix problem with install prefix & application bundles

> On June 18, 2016, 11:17 a.m., René J.V. Bertin wrote: > > AFAIK emerge is not an OS X utility, but something ported from elsewhere. > > Does it use `-DBUNDLE_INSTALL_DIR` and if not, why? > > > > A few remarks re: kded5. AFAICT this is one of those things that should > > *not* be installed

Re: Review Request 128202: Fix problem with install prefix & application bundles

> On June 18, 2016, 11:17 a.m., René J.V. Bertin wrote: > > kde-modules/KDEInstallDirs.cmake, line 388 > > > > > > Is this going to change anything when you define BUNDLE_INSTALL_DIR on > > the commandline? >

Re: Review Request 128202: Fix problem with install prefix & application bundles

> On June 18, 2016, 11:17 a.m., René J.V. Bertin wrote: > > AFAIK emerge is not an OS X utility, but something ported from elsewhere. > > Does it use `-DBUNDLE_INSTALL_DIR` and if not, why? > > > > A few remarks re: kded5. AFAICT this is one of those things that should > > *not* be installed

Re: Review Request 128202: Fix problem with install prefix & application bundles

> On June 18, 2016, 11:17 a.m., René J.V. Bertin wrote: > > kde-modules/KDEInstallDirs.cmake, line 388 > > > > > > Is this going to change anything when you define BUNDLE_INSTALL_DIR on > > the commandline? >

Re: QSP patch/activator (Review Request 126125: [OS X] make KDE's trash use the OS X trash)

On Saturday December 12 2015 19:32:34 David Faure wrote: Somehow I never got around to answering this. Also directing this back to the lists. > I didn't mean switching at runtime. I mean using KF5 in Qt apps. > I'm pretty sure we had this discussion already but here we go again: > If a pure Qt

Re: Review Request 126624: respect "ShowIconsOnButtons" in the Qt5/KF5 style

> On Jan. 11, 2016, 4:17 p.m., Yichao Yu wrote: > > qt5/style/qtcurve_api.cpp, line 3211 > > > > > > Should this be turned on only when KF5 is enabled? > > Aleix Pol Gonzalez wrote: > KGlobalSettings is

Re: Review Request 126624: respect "ShowIconsOnButtons" in the Qt5/KF5 style

> On Jan. 11, 2016, 4:17 p.m., Yichao Yu wrote: > > qt5/style/qtcurve_api.cpp, line 3211 > > > > > > Should this be turned on only when KF5 is enabled? > > Aleix Pol Gonzalez wrote: > KGlobalSettings is

Re: QSP patch/activator

On Sunday January 10 2016 18:43:25 David Faure wrote: > Otherwise where do you draw the line? You say "One or two", does that mean > that when you get to three frameworks > you suddenly switch to case 2? Of course not ;) Indeed, but see below. > In the qt5/kf5 world, there is only ONE kind of

Re: Review Request 126725: prevent crash-on-exit in KSelectAction::~KSelectAction

> On Jan. 12, 2016, 10:49 p.m., David Faure wrote: > > Can I see the backtrace, with a description of how this gets triggered? I'm > > not sure the issue is fully understood (as shown by the use of "might" in > > the description...). > > > > Is the action being destroyed by clicking into a

Re: Review Request 126725: prevent crash-on-exit in KSelectAction::~KSelectAction

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126725/ --- (Updated Jan. 14, 2016, 12:21 p.m.) Review request for KDE Frameworks

Re: Review Request 126725: prevent crash-on-exit in KSelectAction::~KSelectAction

> On Jan. 12, 2016, 10:49 p.m., David Faure wrote: > > Can I see the backtrace, with a description of how this gets triggered? I'm > > not sure the issue is fully understood (as shown by the use of "might" in > > the description...). > > > > Is the action being destroyed by clicking into a

Re: Review Request 126624: respect "ShowIconsOnButtons" in the Qt5/KF5 style

> On Jan. 11, 2016, 4:17 p.m., Yichao Yu wrote: > > qt5/style/qtcurve_api.cpp, line 3211 > > > > > > Should this be turned on only when KF5 is enabled? > > Aleix Pol Gonzalez wrote: > KGlobalSettings is

opening dialogs using a "foreign" WId

Hi, Allow me to bring back up something that I've maybe never tried to discuss as an individual topic: dialogs that are created using a WId instance that is owned by a different application. Example: the warnings and password dialogs posted by kwalletd, which are supposed to open in a window

Re: QSP patch/activator

David, In your idea of a QSP::addStandardLocation() approach, would that always add to a "global" list (= affect all subsequent calls to standardLocations()), or would you also consider a variant that only affects the next call? Also, if you think we should avoid thinking of this as "providing

Re: Review Request 126624: respect "ShowIconsOnButtons" in the Qt5/KF5 style

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

Re: QSP patch/activator

On Monday January 11 2016 18:58:08 David Faure wrote: Sorry for the silence, I'm trying to force myself to devote my attention to other things that should have priority right now. > We can get cohesion without subclassing QApplication, that's for sure. The question is how. I'm not saying it's

Re: QProcess for GUI apps on OSX, or maybe a KProcess::launchGUIApplication() proof-of-concept?

On Tuesday January 05 2016 12:55:57 David Faure wrote: >No worries, we're both evolving our thoughts as the discussion progresses. Slowly but (I think) surely :) Feedback on the Qt ML thread is inclining me to design an initial proof of concept implementation extending KProcess, probably even

Re: opening dialogs using a "foreign" WId

Martin Graesslin wrote: > That depends on the Wayland compositor. In Plasma (KWin) we will certainly > make sure this works properly. I'd appreciate if that could be done in a way that makes sense on other platforms too... > But yes currently it most likely will open > somewhere behind just

Re: opening dialogs using a "foreign" WId

Martin Graesslin wrote: > Sorry, we *are* the platform. If we extend the desktop shell to [...] With all due respect, that sounds very wrong for software that's supposed to be cross-platform. At the very least those desktop shell extensions should be accessed via KF5 or Qt APIs designed to

Re: QSP patch/activator

And here's the business part of the latest version of my QSP patch, by popular request (or not) :) I've followed your (David's) remark that the actual QExtStandardPaths payload could be part of QStandardPaths; QExtStandardPaths is now purely header based - in qstandardpaths.h to be exact. The

Re: opening dialogs using a "foreign" WId

Martin Graesslin wrote: > What we do is take the KF5 based software and integrate it into our platform. > That's the same as you are doing. You integrate KF5 based software into OSX. > The only difference is that we also have full control over the platform. > > So far where we have done this we

Re: opening dialogs using a "foreign" WId

René J. V. Bertin wrote: > Which is all I'm hinting at, and certainly not that a single (or small group > of) person(s) implement this for all platforms. Of course, if cross-process WIds are basically only usable under X11/Xcb one could probably replace their use with som

Re: QSP patch/activator

Hi, I was just reminded of a related issue. The native Mac platform theme has a very limited icon theme search path. You can add the XDG-compliant icon repository to that path, but then almost all buttons will start to show icons: the platform theme apparently doesn't even check the

Re: QSP patch/activator

On Sunday January 31 2016 12:10:05 David Faure wrote: > On Sunday 31 January 2016 11:18:34 René J.V. Bertin wrote: > > +case QPlatformTheme::IconThemeSearchPaths: > > +if (QStandardPaths::isXDGLocationsEnabled()) { > > +return xdgIconThemePaths(); > > +} > > I

Re: Review Request 126291: initial implementation of a platform plugin for OS X (WIP)

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126291/ --- (Updated Feb. 23, 2016, 10:54 p.m.) Review request for KDE Software on

Re: Review Request 126291: initial implementation of a platform plugin for OS X (WIP)

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126291/ --- (Updated Feb. 28, 2016, 6:15 p.m.) Review request for KDE Software on

Re: Review Request 126291: initial implementation of a platform plugin for OS X (WIP)

> On Feb. 25, 2016, 8:26 a.m., Martin Gräßlin wrote: > > I don't like the introduction of the SCRAPBOOK. The repository is not the > > place for dead and old code. That's what git already supports with keeping > > the whole history. > > > > We have some autotests for kwindowsystem. Could you

Re: Review Request 126291: initial implementation of a platform plugin for OS X (WIP)

> On Feb. 25, 2016, 8:26 a.m., Martin Gräßlin wrote: > > I don't like the introduction of the SCRAPBOOK. The repository is not the > > place for dead and old code. That's what git already supports with keeping > > the whole history. > > > > We have some autotests for kwindowsystem. Could you

Re: Review Request 126291: initial implementation of a platform plugin for OS X (WIP)

> On Feb. 25, 2016, 8:26 a.m., Martin Gräßlin wrote: > > I don't like the introduction of the SCRAPBOOK. The repository is not the > > place for dead and old code. That's what git already supports with keeping > > the whole history. > > > > We have some autotests for kwindowsystem. Could you

about rpath "automagic" (CMAKE_INSTALL_RPATH)

Hello, I've been building KF5 projects on OS X and Linux, using /opt/local as the install prefix, but with Qt5 tucked away partly into /opt/local/libexec/qt5 in order to allow it to co-exist with Qt4 in the same prefix. The build system I use will typically turn on explicit rpaths if such a

Re: Review Request 126725: prevent crash-on-exit in KSelectAction::~KSelectAction

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126725/ --- (Updated Jan. 19, 2016, 2:09 p.m.) Status -- This change has been

Re: opening dialogs using a "foreign" WId

Kai Uwe Broulik wrote: Hi, >> ‎Are there other platforms where WIds cannot be used for this kind of use >> case (MS Windows for instance)? > > Wayland.‎ So how do the dialogs behave when, say, kwalletmanager asks kwalletd to unlock a locked keychain and a password or passphrase is required?

Re: Review Request 126291: initial implementation of a platform plugin for OS X (WIP)

> On Feb. 15, 2016, 8:42 a.m., Martin Gräßlin wrote: > > Thanks for contributing the code, I'm very happy to see this happening! > > Sorry, that I cannot provide a good review as I'm not really into the OSX > > API, thus my review here might look a little bit nitpicky. > > > > General

Re: Review Request 126291: initial implementation of a platform plugin for OS X (WIP)

> On Feb. 15, 2016, 8:42 a.m., Martin Gräßlin wrote: > > Thanks for contributing the code, I'm very happy to see this happening! > > Sorry, that I cannot provide a good review as I'm not really into the OSX > > API, thus my review here might look a little bit nitpicky. > > > > General

Re: Review Request 126291: initial implementation of a platform plugin for OS X (WIP)

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126291/ --- (Updated Feb. 17, 2016, 12:23 a.m.) Review request for KDE Software on

Re: RCC for icons - update: Re: Icons installed by apps

On Thursday February 18 2016 19:47:04 Jaroslaw Staniek wrote: > ​Sure but we all agree that outside of desktops adjusted for the taste of > geeks XDG isn't part of these OSes. You are missing the point. The icon theme search path will contain the XDG icon location by default on systems where

building everything with a set of specific preprocessor token(s)/definition(s)?

Hi, I'd like to investigate something Qt-related that would require me to build all frameworks with a specific set of preprocessor tokens defined. Rather than patching all toplevel CMake files I'm hoping for way to define those tokens in the cmake invocation, IOW on the cmake command line. It

Re: building everything with a set of specific preprocessor token(s)/definition(s)?

On Sunday February 14 2016 15:20:14 David Faure wrote: > export CXXFLAGS="-DMYDEFINE=1" before running cmake should do the trick. That's what I'm using ATM, but cmake has a nasty habit of not taking the user's full CXXFLAGS and/or adding its own stuff to the resulting

Re: Review Request 126291: initial implementation of a platform plugin for OS X (WIP)

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126291/ --- (Updated Feb. 14, 2016, 5:44 p.m.) Review request for KDE Software on

Re: Qt 5.6/QtWebkit

David Edmundson wrote: > There was a thread "Policy regarding QtWebKit and QtScript" on > kde-core-devel a while ago. > http://kde.6490.n7.nabble.com/Policy-regarding-QtWebKit-and-QtScript-td1619988.html Indeed there was, a short while ago even. It mostly argues about the cost of building

Re: Qt 5.6/QtWebkit (got it, now to build it)

René J. V. Bertin wrote: >> Webkit packages can be found from here: >> http://download.qt.io/community_releases/5.6/5.6.0/ I presume there must be at least one member on this list who managed to build QtWebKit 5.6.0 (and remembers how)? Sorry about asking on here, but I'm not

Re: building everything with a set of specific preprocessor token(s)/definition(s)?

Boudhayan Gupta wrote: Sorry, I've been overlooking this thread completely (been going through a bit of a rough patch in life). > > CC="gcc -DWHATEVER_DEFINE" cmake ... > > It really should be as simple as that. Yeah, except that this would very likely apply too: > There's also an

Re: Qt 5.6/QtWebkit

David Edmundson wrote: > There was a thread "Policy regarding QtWebKit and QtScript" on > kde-core-devel a while ago. > http://kde.6490.n7.nabble.com/Policy-regarding-QtWebKit-and-QtScript-td1619988.html What I'm missing (as in not getting) in that discussion is the whole thing about

Re: Review Request 126161: OS X housekeeping

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126161/ --- (Updated April 6, 2016, 7:16 p.m.) Review request for KDE Software on

Re: Review Request 126161: OS X housekeeping

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126161/ --- (Updated April 6, 2016, 7:15 p.m.) Review request for KDE Software on

Re: Review Request 126520: [OS X] try to [k]launch the requested application in the foreground [showcase]

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126520/ --- (Updated April 6, 2016, 7:18 p.m.) Review request for KDE Software on

Re: Review Request 126161: OS X housekeeping

> On April 10, 2016, 10:31 a.m., David Faure wrote: > > I liked what I was seeing in this patch until I got to the horrible > > code duplication introduced by kinit_mac.mm. This is not the way to go. > > Yes #ifdefs are a pain, but code duplication is 1000 times worse. In Qt, > > the

Review Request 127635: use QSettings::IniFormat

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127635/ --- Review request for KDE Frameworks and Martin Tobias Holmedahl Sandsmark.

official guidelines on the install location of cmake modules?

Hi, Re-post from the general KDE ML (sorry about that). Is there any official set of guidelines/rules concerning where the cmake modules that come with KDE libraries (incl. the frameworks) can be installed? I've stumbled upon the importance of that location for at least 2 libraries (grantlee

Re: [sonnet] about the QSettings format

On Monday April 11 2016 09:44:26 Martin Sandsmark wrote: Morning, It seems I was a bit confused. I posted this question because I had to introduce a new patch to force the use of IniFormat, but that was not in Sonnet itself but for some new setting in KTextWidgets :-/ Same question/principle

Re: Review Request 126520: [OS X] try to [k]launch the requested application in the foreground [showcase]

> On April 6, 2016, 7:26 p.m., Aleix Pol Gonzalez wrote: > > src/klauncher/klauncher.h, line 279 > > > > > > You shoudln't/can't have Q* classes outside of Qt. > > > > Also does this really need to be

Re: Qt 5.6/QtWebkit

On Friday March 18 2016 17:39:18 Milian Wolff wrote: > > If so it seems it should have been possible to reimplement QtWebKit using a > > similar approach with probably far fewer API changes. > > Which WebKit implementation would you have chosen? The GTK one? Huh?? Upstream WebKit is probably

Re: Qt 5.6/QtWebkit

Aleix Pol wrote: > WebKit integration was done through forking then integrating. It was > awkward because merging upstream changes meant rebasing our work on > theirs. > That's why it's Chromium is better in this regard, you get to interact > the upstream component without forking it, AFAIU.

Re: Qt 5.6/QtWebkit

Kevin Funk wrote: > I think qt-developm...@qt-project.org is a better fit for this question. Good call. From Jani Heikkinen: > Webkit packages can be found from here: > http://download.qt.io/community_releases/5.6/5.6.0/ R. ___

Qt 5.6/QtWebkit

Hi, Is there a page/site somewhere that outlines the current status of Qt 5.6/KF5 compatibility, notably as far as QtWebkit is concerned? A quick search (KF5 qt5.6 qtwebkit) didn't turn up any particularly useful hits in the first page or so, other than that one can apparently still build

Re: Qt 5.6/QtWebkit

Aleix Pol wrote: > > https://code.qt.io/cgit/qt/qtwebkit.git/ Right, thanks, I'd seen that one too (there's also a clone on github but it isn't clear how recent/unmodified that one is). What I didn't yet see is if there's a way to do tarball fetches from code.qt.io that correspond to a

Re: Qt 5.6/QtWebkit (got it, now to build it)

Antonio Rojas wrote: > Besides generating headers with syncqt.pl, you need to backport a patch to > fix linking to pthread Yeah, that's on Linux, though I got the impression not everyone had to apply the patch. I'm homing in on whatever issue it is that causes my standalone build to fail

Re: Review Request 126291: initial implementation of a platform plugin for OS X (WIP)

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126291/ --- (Updated March 4, 2016, 8:19 p.m.) Review request for KDE Software on

Re: RCC for icons - update: Re: Icons installed by apps

On Monday March 07 2016 12:41:52 Jaroslaw Staniek wrote: >I am trying to use app-defined icons through QIcon::fromTheme() in Kexi. That sounds inherently wrong unless the application adds icons to specific themes. Icons that are specific to an application are (almost) by definition not part of

kauth testing?

Hi, KAuth doesn't come with anything but a few unittests that do not appear to attempt an actual authentication. I build my K*5 stuff for installation into /opt/local, under OS X and under KUbuntu 14.04 (i.e. a KDE4 desktop). That excludes almost everything related to Plasma5 desktops and I

Re: kauth testing?

Martin Graesslin wrote: > did it build the mac or the fake backend? On OS X, the Mac backend, and the polkit-qt-1 backend on Linux. I'm not 100% sure of the exact error on OS X because the notification popups don't work properly (they just show the title/caption). That's another point; I

[sonnet] about the QSettings format

Hi, Wasn't it decided a while ago (5.16.0 or so) that frameworks would use QSettings::IniFormat and not QSettings::NativeFormat unless they had a very good reason, in order to have the same file format across platforms and avoid storing things in the registry under MS Windows? R.

Re: [KIO] cookie service and installing in a parallel prefix (/opt/local)

On Friday April 22 2016 23:33:27 René J.V. Bertin wrote: > Looks like I'm going to have to add output to kio_http and see if the error > message doesn't come from an error==ENOENT returned from a failed function > call. Seems like something that's going to be fun ... Looking at when http.cpp

[KIO] cookie service and installing in a parallel prefix (/opt/local)

Hi, I'm installing K*5 in a parallel prefix (/opt/local) that also includes Qt, on OS X and Linux. On OS X the DBus lives in there while on Linux (KUbuntu 14.04) I use the system's DBus which is configured to be aware of /opt/local/share too. This works for just about everything, but I cannot

Re: [KIO] cookie service and installing in a parallel prefix (/opt/local)

On Friday April 22 2016 10:19:35 David Faure wrote: > kcookiejar5 is just a client-side tool (*). And not the tool that applications use to manage cookies? > The actual service is provided by a kded module. You can see if it works by > doing > $ qdbus org.kde.kcookiejar5 /modules/kcookiejar

Re: Review Request 126161: OS X housekeeping

> On April 10, 2016, 10:31 a.m., David Faure wrote: > > src/klauncher/klauncher_main.cpp, line 152 > > > > > > I'm curious, what's the difference between Q_OS_DARWIN and Q_OS_OSX? Q_OS_DARWIN incorporates all

Re: Review Request 126161: OS X housekeeping

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126161/ --- (Updated April 22, 2016, 6:03 p.m.) Review request for KDE Software on

Re: [KIO] cookie service and installing in a parallel prefix (/opt/local)

On Friday April 22 2016 15:28:35 David Faure wrote: > It is, but with a different name. In KDE4 it's > $ qdbus org.kde.kded /modules/kcookiejar > > I moved it to the name "org.kde.kcookiejar5" so that later it can be hosted > by kiod rather than kded5, transparently. Right. So, any ideas

case in filenames

Hi, Is there an official guideline concerning the use of case for distinguishing between filenames? There are (or have been) a few ports that do this for header files (or directories). In that case it's relatively easy to catch once you build on a case-insensitive FS like found on OS X

Re: [KIO] cookie service and installing in a parallel prefix (/opt/local)

On Friday April 22 2016 20:38:09 David Faure wrote: >> but the cookies KCM considers that the service isn't running? I'd expect >> something OS X-specific in the KCM if this didn't happen on Linux too. > >Ah, that was a bug. >Fixed --

Re: [KIO] cookie service and installing in a parallel prefix (/opt/local)

On Friday April 22 2016 21:28:56 David Faure wrote: > Yep. A qt5/kf5 based konqueror isn't released yet, so who would need this > yet... There's a frameworks branch in kde-baseapps that provides "konqueror5", which isn't missing too much from what I can see ... > (dunno about rekonq). I only

Re: Review Request 126198: [OS X] adaptations for the KdePlatformTheme

> On May 17, 2016, 4:37 p.m., Martin Gräßlin wrote: > > given that Plasma integration got removed I suggest to create a dedicated > > osx-integration repository for it as well. > > René J.V. Bertin wrote: > I quite like the way things are, but yes, I've played with that idea. > >

Re: Review Request 127972: Always update the Predicate parser from y/l sources

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127972/#review95644 --- Looks good but I'll try to do a test-build during one of my

Re: Review Request 126198: [OS X] adaptations for the KdePlatformTheme

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126198/#review95726 --- I've tweaked defaults provided by the theme plugin a bit

Re: Review Request 126198: [OS X] adaptations for the KdePlatformTheme

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126198/ --- (Updated May 23, 2016, 10:23 p.m.) Review request for KDE Software on

Re: Review Request 126198: [OS X] adaptations for the KdePlatformTheme

> On May 17, 2016, 4:37 p.m., Martin Gräßlin wrote: > > given that Plasma integration got removed I suggest to create a dedicated > > osx-integration repository for it as well. > > René J.V. Bertin wrote: > I quite like the way things are, but yes, I've played with that idea. > >

Re: Review Request 126198: [OS X] adaptations for the KdePlatformTheme

> On May 17, 2016, 4:37 p.m., Martin Gräßlin wrote: > > given that Plasma integration got removed I suggest to create a dedicated > > osx-integration repository for it as well. > > René J.V. Bertin wrote: > I quite like the way things are, but yes, I've played with that idea. > >

Re: Review Request 126198: [OS X] adaptations for the KdePlatformTheme

> On May 17, 2016, 4:37 p.m., Martin Gräßlin wrote: > > given that Plasma integration got removed I suggest to create a dedicated > > osx-integration repository for it as well. > > René J.V. Bertin wrote: > I quite like the way things are, but yes, I've played with that idea. > >

Re: Review Request 126198: [OS X] adaptations for the KdePlatformTheme

> On May 17, 2016, 4:37 p.m., Martin Gräßlin wrote: > > given that Plasma integration got removed I suggest to create a dedicated > > osx-integration repository for it as well. > > René J.V. Bertin wrote: > I quite like the way things are, but yes, I've played with that idea. > >

Re: Review Request 127972: Always update the Predicate parser from y/l sources

> On May 21, 2016, 1:21 a.m., René J.V. Bertin wrote: > > I've done some testing with Solid 5.20.0 .The patch applies cleanly, but > > I'm getting the error below. I'd write that down to using the older Solid > > version if it weren't for that fact I'm quite sure I've seen this kind of > >

Review Request 128002: address alignment issue with the OS X native "macintosh" style

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

Re: Review Request 128002: address alignment issue with the OS X native "macintosh" style

On Tuesday May 24 2016 12:50:38 René J.V. Bertin wrote: > other widgets remain to be done > https://git.reviewboard.kde.org/r/128002/file/3043/ Does someone know (without delving deep into source code) what widget classes I might try to patch with a similar fix? R.

Review Request 128005: fix alignment issue with the OS X native "macintosh" style

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

Re: Review Request 127896: make dbus optional on osx: kauth

> On May 21, 2016, 10:20 p.m., Kåre Särs wrote: > > CMakeLists.txt, line 12 > > > > > > Why is this not: option(DISABLE_DBUS "Remove..." OFF) ? > > > > For the rest I'm happy :) Idem. Isn't there a

Re: Review Request 127972: Always update the Predicate parser from y/l sources

> On May 21, 2016, 1:21 a.m., René J.V. Bertin wrote: > > I've done some testing with Solid 5.20.0 .The patch applies cleanly, but > > I'm getting the error below. I'd write that down to using the older Solid > > version if it weren't for that fact I'm quite sure I've seen this kind of > >

Re: Review Request 127972: Always update the Predicate parser from y/l sources

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127972/#review95657 --- I've done some testing with Solid 5.20.0 .The patch applies

Re: Review Request 127822: address the potential name/case clash of the Attica/Attica and Attica/attica header dirs

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127822/#review95384 --- src/CMakeLists.txt (lines 160 - 163)

Re: Review Request 127896: make dbus optional on osx: kauth

> On May 12, 2016, 8:15 a.m., Kåre Särs wrote: > > I think this patch should not include any platform specific defines. > > Disabling DBus requirement on Windows might also be interesting for some > > projects. I propose to do something similar to what is done in kxmlgui to > > disable

Re: Review Request 127896: make dbus optional on osx: kauth

> On May 12, 2016, 8:15 a.m., Kåre Särs wrote: > > I think this patch should not include any platform specific defines. > > Disabling DBus requirement on Windows might also be interesting for some > > projects. I propose to do something similar to what is done in kxmlgui to > > disable

Re: Review Request 127896: make dbus optional on osx: kauth

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127896/#review95403 --- Forgive me if I'd like to be certain that this isn't

Re: Review Request 127896: make dbus optional on osx: kauth

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127896/#review95402 --- Erm, it seems I did something I shouldn't have done,

Re: Review Request 126198: [OS X] adaptations for the KdePlatformTheme

> On May 17, 2016, 4:37 p.m., Martin Gräßlin wrote: > > given that Plasma integration got removed I suggest to create a dedicated > > osx-integration repository for it as well. I quite like the way things are, but yes, I've played with that idea. I guess I can simply fork

Re: Review Request 126198: [OS X] adaptations for the KdePlatformTheme

> On May 17, 2016, 4:36 p.m., Martin Gräßlin wrote: > > > I saw that one of the justifications for the move was a dependency on > > > Plasma library/ies, but I don't see any such dependencies in the latest > > > version before the move (commit 07548ac1fe7a7fb31a941473911e982fb623c07d). > > >

Re: Review Request 126198: [OS X] adaptations for the KdePlatformTheme

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126198/ --- (Updated May 16, 2016, 9:49 p.m.) Review request for KDE Software on Mac

Re: Review Request 126198: [OS X] adaptations for the KdePlatformTheme

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126198/ --- (Updated May 16, 2016, 3:21 p.m.) Review request for KDE Software on Mac

Re: KActivities outside of plasma5 sessions

Ivan Čukić wrote: > The daemon is in kactivitymanagerd repository, nothing to do with plasma. Evidently, the (git) repositories aren't split up in categories. However, the current release download is here http://download.kde.org/stable/plasma/5.6.4/kactivitymanagerd-5.6.4.tar.xz together with

Re: Review Request 127896: make dbus optional on osx: kauth

> On May 12, 2016, 7:43 a.m., René J.V. Bertin wrote: > > autotests/BackendsManager.cpp, lines 56-60 > > > > > > Ditto, no risk of a build failure on systems where Qt does provide a > > DBus interface? > > Nick

<    1   2   3   4   5   6   7   8   9   10   >