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

[David Faure]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127896/#review95710
---



Yes this should use OPTION() so that it shows up in cmake's various GUIs.

René: IMHO INCLUDE_DBUS_SUPPORT sounds like it's off by default, i.e. someone 
experiencing a bug might think they need to first enable dbus support... The 
option isn't to include, but to disable.

- David Faure


On May 20, 2016, 9:13 p.m., Nick Shaforostoff wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127896/
> ---
> 
> (Updated May 20, 2016, 9:13 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Frameworks, David Edmundson, 
> and Martin Gräßlin.
> 
> 
> Repository: kauth
> 
> 
> Description
> ---
> 
> this is the first patch to make kde frameworks build (and then work) without 
> dbus.
> 
> this will allow homebrew users use precompiled vanilla Qt to build kde apps 
> on osx. as dbus is not a common service in osx world, kde apps on osx should 
> use native means for interprocess communication instead -- this will make 
> them better citizens in osx ecosystem.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 48dc2d9 
>   autotests/BackendsManager.cpp 59675b3 
>   autotests/CMakeLists.txt b53d760 
>   autotests/HelperTest.cpp 8050a06 
>   src/CMakeLists.txt 1b6930d 
>   src/ConfigureChecks.cmake d46761a 
> 
> Diff: https://git.reviewboard.kde.org/r/127896/diff/
> 
> 
> Testing
> ---
> 
> compiles fine on osx, compiles fine on linux, tests on linux still pass.
> 
> 
> Thanks,
> 
> Nick Shaforostoff
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

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

[David Edmundson]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127896/#review95394
---




src/CMakeLists.txt (line 32)


In theory - nothing in KAuth should be using DBus outside of the helpers.
(and that autotest that uses the helper)

You should be able to make this change unconditionally - and move finding 
DBus to src/ConfigureChecks cmake

Then we can change those autotests to use the right backend depending on 
which backend get built - which is more semantically correct.

Otherwise we still have a problem that I can manually select the fake 
backend via KAUTH_HELPER_BACKEND_NAME, yet still end up using a test requiring 
DBus for something that isn't being built.


- David Edmundson


On May 20, 2016, 9:13 p.m., Nick Shaforostoff wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127896/
> ---
> 
> (Updated May 20, 2016, 9:13 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Frameworks, David Edmundson, 
> and Martin Gräßlin.
> 
> 
> Repository: kauth
> 
> 
> Description
> ---
> 
> this is the first patch to make kde frameworks build (and then work) without 
> dbus.
> 
> this will allow homebrew users use precompiled vanilla Qt to build kde apps 
> on osx. as dbus is not a common service in osx world, kde apps on osx should 
> use native means for interprocess communication instead -- this will make 
> them better citizens in osx ecosystem.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 48dc2d9 
>   autotests/BackendsManager.cpp 59675b3 
>   autotests/CMakeLists.txt b53d760 
>   autotests/HelperTest.cpp 8050a06 
>   src/CMakeLists.txt 1b6930d 
>   src/ConfigureChecks.cmake d46761a 
> 
> Diff: https://git.reviewboard.kde.org/r/127896/diff/
> 
> 
> Testing
> ---
> 
> compiles fine on osx, compiles fine on linux, tests on linux still pass.
> 
> 
> Thanks,
> 
> Nick Shaforostoff
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

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

[René J . V . Bertin]

> 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 guideline against negative options? IOW, wouldn't it be better to 
have something like

`option(INCLUDE_DBUS_SUPPORT "Include support for using DBus to ..." ON)`

so that you don't have to test on `NOT FOO` everywhere?

(I know it's common practice to use shortcuts like "--disable-dbus" to indicate 
"disable support for dbus", but we can just as well use an option name that's 
semantically correct, no? :) )


- René J.V.


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127896/#review95681
---


On May 20, 2016, 11:13 p.m., Nick Shaforostoff wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127896/
> ---
> 
> (Updated May 20, 2016, 11:13 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Frameworks, David Edmundson, 
> and Martin Gräßlin.
> 
> 
> Repository: kauth
> 
> 
> Description
> ---
> 
> this is the first patch to make kde frameworks build (and then work) without 
> dbus.
> 
> this will allow homebrew users use precompiled vanilla Qt to build kde apps 
> on osx. as dbus is not a common service in osx world, kde apps on osx should 
> use native means for interprocess communication instead -- this will make 
> them better citizens in osx ecosystem.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 48dc2d9 
>   autotests/BackendsManager.cpp 59675b3 
>   autotests/CMakeLists.txt b53d760 
>   autotests/HelperTest.cpp 8050a06 
>   src/CMakeLists.txt 1b6930d 
>   src/ConfigureChecks.cmake d46761a 
> 
> Diff: https://git.reviewboard.kde.org/r/127896/diff/
> 
> 
> Testing
> ---
> 
> compiles fine on osx, compiles fine on linux, tests on linux still pass.
> 
> 
> Thanks,
> 
> Nick Shaforostoff
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

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

[Kåre Särs]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127896/#review95681
---




CMakeLists.txt (line 12)


Why is this not: option(DISABLE_DBUS "Remove..." OFF) ?

For the rest I'm happy :)


- Kåre Särs


On May 20, 2016, 9:13 p.m., Nick Shaforostoff wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127896/
> ---
> 
> (Updated May 20, 2016, 9:13 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Frameworks, David Edmundson, 
> and Martin Gräßlin.
> 
> 
> Repository: kauth
> 
> 
> Description
> ---
> 
> this is the first patch to make kde frameworks build (and then work) without 
> dbus.
> 
> this will allow homebrew users use precompiled vanilla Qt to build kde apps 
> on osx. as dbus is not a common service in osx world, kde apps on osx should 
> use native means for interprocess communication instead -- this will make 
> them better citizens in osx ecosystem.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 48dc2d9 
>   autotests/BackendsManager.cpp 59675b3 
>   autotests/CMakeLists.txt b53d760 
>   autotests/HelperTest.cpp 8050a06 
>   src/CMakeLists.txt 1b6930d 
>   src/ConfigureChecks.cmake d46761a 
> 
> Diff: https://git.reviewboard.kde.org/r/127896/diff/
> 
> 
> Testing
> ---
> 
> compiles fine on osx, compiles fine on linux, tests on linux still pass.
> 
> 
> Thanks,
> 
> Nick Shaforostoff
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

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

[Nick Shaforostoff]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127896/
---

(Updated May 20, 2016, 9:13 p.m.)


Review request for KDE Software on Mac OS X, KDE Frameworks, David Edmundson, 
and Martin Gräßlin.


Changes
---

made dbus enabling/disabling be available via cmake config option only, as asked


Repository: kauth


Description
---

this is the first patch to make kde frameworks build (and then work) without 
dbus.

this will allow homebrew users use precompiled vanilla Qt to build kde apps on 
osx. as dbus is not a common service in osx world, kde apps on osx should use 
native means for interprocess communication instead -- this will make them 
better citizens in osx ecosystem.


Diffs (updated)
-

  CMakeLists.txt 48dc2d9 
  autotests/BackendsManager.cpp 59675b3 
  autotests/CMakeLists.txt b53d760 
  autotests/HelperTest.cpp 8050a06 
  src/CMakeLists.txt 1b6930d 
  src/ConfigureChecks.cmake d46761a 

Diff: https://git.reviewboard.kde.org/r/127896/diff/


Testing
---

compiles fine on osx, compiles fine on linux, tests on linux still pass.


Thanks,

Nick Shaforostoff

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

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

[René J . V . Bertin]

> 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 kglobalaccel. The default is to require kglobalaccel, but if you 
> > knowingly specify "-DFORCE_DISABLE_KGLOBALACCEL=1" kglobalaccel is not 
> > required or searched for.
> 
> René J.V. Bertin wrote:
> True, even if there's probably very little point in disabling DBus on a 
> standard Unix/Linux set-up.
> 
> But indeed, a platform-agnostic option can still be included in the 
> options that will be flipped by a platform-specific option like 
> `APPLE_STANDALONE_BUNDLE` I've proposed in a patch for Marble.
> 
> To come back to what I suggested earlier: even if there were to be a KF5 
> framework that encapsulates DBus or "something more platform native" there 
> would still be a use-case for using DBus through that framework even on OS X 
> (or MS Windows). Projects like HomeBrew, MacPorts and Cygwin don't exist to 
> replace the native desktop, but to complement it; to provide an easy way to 
> install and maintain FOSS and provide a context in which those applications 
> can run as much as possible as they do on their native platform. That 
> evidently includes DBus, but not just so that Gnome apps can talk with other 
> Gnome apps and KDE apps with other KDE apps. I don't have any stats on this, 
> but I'd expect that a good many of the users of such projects use them not so 
> much for software development per se, but as tools for their actual work 
> (often in science and/or engineering, in my impression). That might very well 
> include using Gnome/GTk apps alongside KDE applications, and in that case 
> they'd proba
 bly expect  the same kind of interoperability as those apps would have on the 
other platforms they might use.
> IOW, I don't think a distribution system that aims to provide the best 
> possible context for the applications it carries can get around using DBus.
> 
> But this is probably not the best place for an in-depth discussion around 
> underlying principles; that should probably be done on a ML (and ideally 
> include a DBus dev or two).
> 
> Nick Shaforostoff wrote:
> i don't see a reason behind introducing a special cmake option other than 
> code coverage (test dbus and dbus-free branches with the same qt): why one 
> should want to disable dbus on a system where he/she has Qt with dbus?
> 
> can you explain this to me?
> 
> regarding homebrew, i repeat: by default it installs a precompiled 
> version of Qt without dbus. if user wants dbus then he/she has to have 
> homebrew recompile whole Qt (takes about 1 hour). and what if kde app doesn't 
> need any IPC? that would just pollute his/her system with redundant stuff. 
> how many gtk-based apps require dbus to run on windows and osx?
> 
> Kåre Särs wrote:
> We have Kate as an example. At the moment the main thing we need DBus for 
> on windows is opening documents in only one window when opening new documents 
> through explorer. Without the DBus daemon it does not work. KDevelop has a 
> solution for it without using DBus which means that we could skip DBus usage 
> for this purpose and we would not need to tell people to install the service 
> (DBus) that occasionally has been flagged as mallware.
> 
> You might argue that we should just compile support without installing 
> the service, but how do I know what features don't work without the service? 
> If the frameworks need special options to disable DBus I'm informed about 
> what is disabled and can choose if I need it or not. Without the option the 
> feature is silently disabled. This is the reason I want separate options for 
> each framework that provides it and not a global one in ECM.
> 
> Almost all Qt users on Windows that I know of would not even dream of 
> compiling their own Qt and pre-compiled Qt comes with DBus support.
> 
> René J.V. Bertin wrote:
> > can you explain this to me?
> 
> An option here would allow using a single Qt install to build and bundle 
> software either with or without support for DBus. 
> 
> I wouldn't worry about the "pollution" aspect of redundant stuff here. 
> There are other things that are just as redundant and pollute a lot more 
> (like "tons of" translation files) and that are still installed because disk 
> space is cheap compared to the potential cost of being overly concerned about 
> the overhead. It's also cheap compared to the cost of building Qt from source.
> 
> I'll repeat something too: if HB considers it appropriate to provide a 
> pre-compiled Qt version that doesn't include DBus support, than it's up to HB 
> to assume any consequences that might have on IPC abilities of dependent 
> packages. For instance by building with a 

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

[Nick Shaforostoff]

> On May 12, 2016, 6: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 kglobalaccel. The default is to require kglobalaccel, but if you 
> > knowingly specify "-DFORCE_DISABLE_KGLOBALACCEL=1" kglobalaccel is not 
> > required or searched for.
> 
> René J.V. Bertin wrote:
> True, even if there's probably very little point in disabling DBus on a 
> standard Unix/Linux set-up.
> 
> But indeed, a platform-agnostic option can still be included in the 
> options that will be flipped by a platform-specific option like 
> `APPLE_STANDALONE_BUNDLE` I've proposed in a patch for Marble.
> 
> To come back to what I suggested earlier: even if there were to be a KF5 
> framework that encapsulates DBus or "something more platform native" there 
> would still be a use-case for using DBus through that framework even on OS X 
> (or MS Windows). Projects like HomeBrew, MacPorts and Cygwin don't exist to 
> replace the native desktop, but to complement it; to provide an easy way to 
> install and maintain FOSS and provide a context in which those applications 
> can run as much as possible as they do on their native platform. That 
> evidently includes DBus, but not just so that Gnome apps can talk with other 
> Gnome apps and KDE apps with other KDE apps. I don't have any stats on this, 
> but I'd expect that a good many of the users of such projects use them not so 
> much for software development per se, but as tools for their actual work 
> (often in science and/or engineering, in my impression). That might very well 
> include using Gnome/GTk apps alongside KDE applications, and in that case 
> they'd proba
 bly expect  the same kind of interoperability as those apps would have on the 
other platforms they might use.
> IOW, I don't think a distribution system that aims to provide the best 
> possible context for the applications it carries can get around using DBus.
> 
> But this is probably not the best place for an in-depth discussion around 
> underlying principles; that should probably be done on a ML (and ideally 
> include a DBus dev or two).
> 
> Nick Shaforostoff wrote:
> i don't see a reason behind introducing a special cmake option other than 
> code coverage (test dbus and dbus-free branches with the same qt): why one 
> should want to disable dbus on a system where he/she has Qt with dbus?
> 
> can you explain this to me?
> 
> regarding homebrew, i repeat: by default it installs a precompiled 
> version of Qt without dbus. if user wants dbus then he/she has to have 
> homebrew recompile whole Qt (takes about 1 hour). and what if kde app doesn't 
> need any IPC? that would just pollute his/her system with redundant stuff. 
> how many gtk-based apps require dbus to run on windows and osx?
> 
> Kåre Särs wrote:
> We have Kate as an example. At the moment the main thing we need DBus for 
> on windows is opening documents in only one window when opening new documents 
> through explorer. Without the DBus daemon it does not work. KDevelop has a 
> solution for it without using DBus which means that we could skip DBus usage 
> for this purpose and we would not need to tell people to install the service 
> (DBus) that occasionally has been flagged as mallware.
> 
> You might argue that we should just compile support without installing 
> the service, but how do I know what features don't work without the service? 
> If the frameworks need special options to disable DBus I'm informed about 
> what is disabled and can choose if I need it or not. Without the option the 
> feature is silently disabled. This is the reason I want separate options for 
> each framework that provides it and not a global one in ECM.
> 
> Almost all Qt users on Windows that I know of would not even dream of 
> compiling their own Qt and pre-compiled Qt comes with DBus support.
> 
> René J.V. Bertin wrote:
> > can you explain this to me?
> 
> An option here would allow using a single Qt install to build and bundle 
> software either with or without support for DBus. 
> 
> I wouldn't worry about the "pollution" aspect of redundant stuff here. 
> There are other things that are just as redundant and pollute a lot more 
> (like "tons of" translation files) and that are still installed because disk 
> space is cheap compared to the potential cost of being overly concerned about 
> the overhead. It's also cheap compared to the cost of building Qt from source.
> 
> I'll repeat something too: if HB considers it appropriate to provide a 
> pre-compiled Qt version that doesn't include DBus support, than it's up to HB 
> to assume any consequences that might have on IPC abilities of dependent 
> packages. For instance by building with a 

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

[René J . V . Bertin]

> 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 kglobalaccel. The default is to require kglobalaccel, but if you 
> > knowingly specify "-DFORCE_DISABLE_KGLOBALACCEL=1" kglobalaccel is not 
> > required or searched for.
> 
> René J.V. Bertin wrote:
> True, even if there's probably very little point in disabling DBus on a 
> standard Unix/Linux set-up.
> 
> But indeed, a platform-agnostic option can still be included in the 
> options that will be flipped by a platform-specific option like 
> `APPLE_STANDALONE_BUNDLE` I've proposed in a patch for Marble.
> 
> To come back to what I suggested earlier: even if there were to be a KF5 
> framework that encapsulates DBus or "something more platform native" there 
> would still be a use-case for using DBus through that framework even on OS X 
> (or MS Windows). Projects like HomeBrew, MacPorts and Cygwin don't exist to 
> replace the native desktop, but to complement it; to provide an easy way to 
> install and maintain FOSS and provide a context in which those applications 
> can run as much as possible as they do on their native platform. That 
> evidently includes DBus, but not just so that Gnome apps can talk with other 
> Gnome apps and KDE apps with other KDE apps. I don't have any stats on this, 
> but I'd expect that a good many of the users of such projects use them not so 
> much for software development per se, but as tools for their actual work 
> (often in science and/or engineering, in my impression). That might very well 
> include using Gnome/GTk apps alongside KDE applications, and in that case 
> they'd proba
 bly expect  the same kind of interoperability as those apps would have on the 
other platforms they might use.
> IOW, I don't think a distribution system that aims to provide the best 
> possible context for the applications it carries can get around using DBus.
> 
> But this is probably not the best place for an in-depth discussion around 
> underlying principles; that should probably be done on a ML (and ideally 
> include a DBus dev or two).
> 
> Nick Shaforostoff wrote:
> i don't see a reason behind introducing a special cmake option other than 
> code coverage (test dbus and dbus-free branches with the same qt): why one 
> should want to disable dbus on a system where he/she has Qt with dbus?
> 
> can you explain this to me?
> 
> regarding homebrew, i repeat: by default it installs a precompiled 
> version of Qt without dbus. if user wants dbus then he/she has to have 
> homebrew recompile whole Qt (takes about 1 hour). and what if kde app doesn't 
> need any IPC? that would just pollute his/her system with redundant stuff. 
> how many gtk-based apps require dbus to run on windows and osx?
> 
> Kåre Särs wrote:
> We have Kate as an example. At the moment the main thing we need DBus for 
> on windows is opening documents in only one window when opening new documents 
> through explorer. Without the DBus daemon it does not work. KDevelop has a 
> solution for it without using DBus which means that we could skip DBus usage 
> for this purpose and we would not need to tell people to install the service 
> (DBus) that occasionally has been flagged as mallware.
> 
> You might argue that we should just compile support without installing 
> the service, but how do I know what features don't work without the service? 
> If the frameworks need special options to disable DBus I'm informed about 
> what is disabled and can choose if I need it or not. Without the option the 
> feature is silently disabled. This is the reason I want separate options for 
> each framework that provides it and not a global one in ECM.
> 
> Almost all Qt users on Windows that I know of would not even dream of 
> compiling their own Qt and pre-compiled Qt comes with DBus support.
> 
> René J.V. Bertin wrote:
> > can you explain this to me?
> 
> An option here would allow using a single Qt install to build and bundle 
> software either with or without support for DBus. 
> 
> I wouldn't worry about the "pollution" aspect of redundant stuff here. 
> There are other things that are just as redundant and pollute a lot more 
> (like "tons of" translation files) and that are still installed because disk 
> space is cheap compared to the potential cost of being overly concerned about 
> the overhead. It's also cheap compared to the cost of building Qt from source.
> 
> I'll repeat something too: if HB considers it appropriate to provide a 
> pre-compiled Qt version that doesn't include DBus support, than it's up to HB 
> to assume any consequences that might have on IPC abilities of dependent 
> packages. For instance by building with a 

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

[René J . V . Bertin]

> 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 kglobalaccel. The default is to require kglobalaccel, but if you 
> > knowingly specify "-DFORCE_DISABLE_KGLOBALACCEL=1" kglobalaccel is not 
> > required or searched for.
> 
> René J.V. Bertin wrote:
> True, even if there's probably very little point in disabling DBus on a 
> standard Unix/Linux set-up.
> 
> But indeed, a platform-agnostic option can still be included in the 
> options that will be flipped by a platform-specific option like 
> `APPLE_STANDALONE_BUNDLE` I've proposed in a patch for Marble.
> 
> To come back to what I suggested earlier: even if there were to be a KF5 
> framework that encapsulates DBus or "something more platform native" there 
> would still be a use-case for using DBus through that framework even on OS X 
> (or MS Windows). Projects like HomeBrew, MacPorts and Cygwin don't exist to 
> replace the native desktop, but to complement it; to provide an easy way to 
> install and maintain FOSS and provide a context in which those applications 
> can run as much as possible as they do on their native platform. That 
> evidently includes DBus, but not just so that Gnome apps can talk with other 
> Gnome apps and KDE apps with other KDE apps. I don't have any stats on this, 
> but I'd expect that a good many of the users of such projects use them not so 
> much for software development per se, but as tools for their actual work 
> (often in science and/or engineering, in my impression). That might very well 
> include using Gnome/GTk apps alongside KDE applications, and in that case 
> they'd proba
 bly expect  the same kind of interoperability as those apps would have on the 
other platforms they might use.
> IOW, I don't think a distribution system that aims to provide the best 
> possible context for the applications it carries can get around using DBus.
> 
> But this is probably not the best place for an in-depth discussion around 
> underlying principles; that should probably be done on a ML (and ideally 
> include a DBus dev or two).
> 
> Nick Shaforostoff wrote:
> i don't see a reason behind introducing a special cmake option other than 
> code coverage (test dbus and dbus-free branches with the same qt): why one 
> should want to disable dbus on a system where he/she has Qt with dbus?
> 
> can you explain this to me?
> 
> regarding homebrew, i repeat: by default it installs a precompiled 
> version of Qt without dbus. if user wants dbus then he/she has to have 
> homebrew recompile whole Qt (takes about 1 hour). and what if kde app doesn't 
> need any IPC? that would just pollute his/her system with redundant stuff. 
> how many gtk-based apps require dbus to run on windows and osx?
> 
> Kåre Särs wrote:
> We have Kate as an example. At the moment the main thing we need DBus for 
> on windows is opening documents in only one window when opening new documents 
> through explorer. Without the DBus daemon it does not work. KDevelop has a 
> solution for it without using DBus which means that we could skip DBus usage 
> for this purpose and we would not need to tell people to install the service 
> (DBus) that occasionally has been flagged as mallware.
> 
> You might argue that we should just compile support without installing 
> the service, but how do I know what features don't work without the service? 
> If the frameworks need special options to disable DBus I'm informed about 
> what is disabled and can choose if I need it or not. Without the option the 
> feature is silently disabled. This is the reason I want separate options for 
> each framework that provides it and not a global one in ECM.
> 
> Almost all Qt users on Windows that I know of would not even dream of 
> compiling their own Qt and pre-compiled Qt comes with DBus support.

> can you explain this to me?

An option here would allow using a single Qt install to build and bundle 
software either with or without support for DBus. 

I wouldn't worry about the "pollution" aspect of redundant stuff here. There 
are other things that are just as redundant and pollute a lot more (like "tons 
of" translation files) and that are still installed because disk space is cheap 
compared to the potential cost of being overly concerned about the overhead. 
It's also cheap compared to the cost of building Qt from source.

I'll repeat something too: if HB considers it appropriate to provide a 
pre-compiled Qt version that doesn't include DBus support, than it's up to HB 
to assume any consequences that might have on IPC abilities of dependent 
packages. For instance by building with a specific cmake switch to disable 
DBus. 
MacPorts also provides pre-compiled packages, 

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

[Kåre Särs]

> On May 12, 2016, 6: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 kglobalaccel. The default is to require kglobalaccel, but if you 
> > knowingly specify "-DFORCE_DISABLE_KGLOBALACCEL=1" kglobalaccel is not 
> > required or searched for.
> 
> René J.V. Bertin wrote:
> True, even if there's probably very little point in disabling DBus on a 
> standard Unix/Linux set-up.
> 
> But indeed, a platform-agnostic option can still be included in the 
> options that will be flipped by a platform-specific option like 
> `APPLE_STANDALONE_BUNDLE` I've proposed in a patch for Marble.
> 
> To come back to what I suggested earlier: even if there were to be a KF5 
> framework that encapsulates DBus or "something more platform native" there 
> would still be a use-case for using DBus through that framework even on OS X 
> (or MS Windows). Projects like HomeBrew, MacPorts and Cygwin don't exist to 
> replace the native desktop, but to complement it; to provide an easy way to 
> install and maintain FOSS and provide a context in which those applications 
> can run as much as possible as they do on their native platform. That 
> evidently includes DBus, but not just so that Gnome apps can talk with other 
> Gnome apps and KDE apps with other KDE apps. I don't have any stats on this, 
> but I'd expect that a good many of the users of such projects use them not so 
> much for software development per se, but as tools for their actual work 
> (often in science and/or engineering, in my impression). That might very well 
> include using Gnome/GTk apps alongside KDE applications, and in that case 
> they'd proba
 bly expect  the same kind of interoperability as those apps would have on the 
other platforms they might use.
> IOW, I don't think a distribution system that aims to provide the best 
> possible context for the applications it carries can get around using DBus.
> 
> But this is probably not the best place for an in-depth discussion around 
> underlying principles; that should probably be done on a ML (and ideally 
> include a DBus dev or two).
> 
> Nick Shaforostoff wrote:
> i don't see a reason behind introducing a special cmake option other than 
> code coverage (test dbus and dbus-free branches with the same qt): why one 
> should want to disable dbus on a system where he/she has Qt with dbus?
> 
> can you explain this to me?
> 
> regarding homebrew, i repeat: by default it installs a precompiled 
> version of Qt without dbus. if user wants dbus then he/she has to have 
> homebrew recompile whole Qt (takes about 1 hour). and what if kde app doesn't 
> need any IPC? that would just pollute his/her system with redundant stuff. 
> how many gtk-based apps require dbus to run on windows and osx?

We have Kate as an example. At the moment the main thing we need DBus for on 
windows is opening documents in only one window when opening new documents 
through explorer. Without the DBus daemon it does not work. KDevelop has a 
solution for it without using DBus which means that we could skip DBus usage 
for this purpose and we would not need to tell people to install the service 
(DBus) that occasionally has been flagged as mallware.

You might argue that we should just compile support without installing the 
service, but how do I know what features don't work without the service? If the 
frameworks need special options to disable DBus I'm informed about what is 
disabled and can choose if I need it or not. Without the option the feature is 
silently disabled. This is the reason I want separate options for each 
framework that provides it and not a global one in ECM.

Almost all Qt users on Windows that I know of would not even dream of compiling 
their own Qt and pre-compiled Qt comes with DBus support.


- Kåre


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127896/#review95405
---


On May 12, 2016, 5:16 a.m., Nick Shaforostoff wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127896/
> ---
> 
> (Updated May 12, 2016, 5:16 a.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Frameworks, David Edmundson, 
> and Martin Gräßlin.
> 
> 
> Repository: kauth
> 
> 
> Description
> ---
> 
> this is the first patch to make kde frameworks build (and then work) without 
> dbus.
> 
> this will allow homebrew users use precompiled vanilla Qt to build kde apps 
> on osx. as dbus is not a common service in osx world, 

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

[René J . V . Bertin]

> 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 Shaforostoff wrote:
> no rosk. please read the 'testing' section of this review request

I did, and it appears you didn't test on OS X with DBus available. That's the 
potential risk I saw.


- René J.V.


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127896/#review95403
---


On May 12, 2016, 7:16 a.m., Nick Shaforostoff wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127896/
> ---
> 
> (Updated May 12, 2016, 7:16 a.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Frameworks, David Edmundson, 
> and Martin Gräßlin.
> 
> 
> Repository: kauth
> 
> 
> Description
> ---
> 
> this is the first patch to make kde frameworks build (and then work) without 
> dbus.
> 
> this will allow homebrew users use precompiled vanilla Qt to build kde apps 
> on osx. as dbus is not a common service in osx world, kde apps on osx should 
> use native means for interprocess communication instead -- this will make 
> them better citizens in osx ecosystem.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 48dc2d9 
>   autotests/BackendsManager.cpp 59675b3 
>   autotests/CMakeLists.txt b53d760 
>   autotests/HelperTest.cpp 8050a06 
>   src/CMakeLists.txt 1b6930d 
>   src/ConfigureChecks.cmake d46761a 
> 
> Diff: https://git.reviewboard.kde.org/r/127896/diff/
> 
> 
> Testing
> ---
> 
> compiles fine on osx, compiles fine on linux, tests on linux still pass.
> 
> 
> Thanks,
> 
> Nick Shaforostoff
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

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

[Nick Shaforostoff]

> On May 12, 2016, 5:43 a.m., René J.V. Bertin wrote:
> > CMakeLists.txt, lines 14-18
> > 
> >
> > Am I right that on OS X use of DBus is going to depend on whether or 
> > not Qt provides the QtDBus component? If so, shouldn't this be done on MS 
> > Windows too?
> > 
> > If that's *not* the right interpretation:
> > PLEASE introduce proper option variables for this kind of thing, for 
> > instance in ECM. Consider the overal picture; is this only about DBus or is 
> > this ultimately about building standalone app bundles? In other words, 
> > would it be possible to name that option variable appropriately to allow it 
> > to act as a switch for other, related build options?
> > 
> > This is all the more appropriate (and *polite*) if this is a 
> > convenience change for HomeBrew - why would such a change oblige other 
> > packaging/distribution systems to add and maintain unknown amounts of 
> > additional patches to undo it?!

yes, on OS X use of DBus is going to depend on whether or not Qt provides the 
QtDBus component.


> On May 12, 2016, 5:43 a.m., René J.V. Bertin wrote:
> > autotests/BackendsManager.cpp, lines 26-30
> > 
> >
> > Again, double-checking: Is QT_NO_DBUS really going to be defined if the 
> > cmake system didn't do a `find_package(Qt5 ... DBus)`? IOW, is this change 
> > not going to introduce a build failure on systems where Qt does provide a 
> > DBus interface?

i tested on linux - it did build fine


> On May 12, 2016, 5: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?

no rosk. please read the 'testing' section of this review request


> On May 12, 2016, 5:43 a.m., René J.V. Bertin wrote:
> > src/CMakeLists.txt, line 2
> > 
> >
> > Was this a redundant statement?

yes, it was redundant.


- Nick


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127896/#review95403
---


On May 12, 2016, 5:16 a.m., Nick Shaforostoff wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127896/
> ---
> 
> (Updated May 12, 2016, 5:16 a.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Frameworks, David Edmundson, 
> and Martin Gräßlin.
> 
> 
> Repository: kauth
> 
> 
> Description
> ---
> 
> this is the first patch to make kde frameworks build (and then work) without 
> dbus.
> 
> this will allow homebrew users use precompiled vanilla Qt to build kde apps 
> on osx. as dbus is not a common service in osx world, kde apps on osx should 
> use native means for interprocess communication instead -- this will make 
> them better citizens in osx ecosystem.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 48dc2d9 
>   autotests/BackendsManager.cpp 59675b3 
>   autotests/CMakeLists.txt b53d760 
>   autotests/HelperTest.cpp 8050a06 
>   src/CMakeLists.txt 1b6930d 
>   src/ConfigureChecks.cmake d46761a 
> 
> Diff: https://git.reviewboard.kde.org/r/127896/diff/
> 
> 
> Testing
> ---
> 
> compiles fine on osx, compiles fine on linux, tests on linux still pass.
> 
> 
> Thanks,
> 
> Nick Shaforostoff
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

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

[Nick Shaforostoff]

> On May 12, 2016, 6: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 kglobalaccel. The default is to require kglobalaccel, but if you 
> > knowingly specify "-DFORCE_DISABLE_KGLOBALACCEL=1" kglobalaccel is not 
> > required or searched for.
> 
> René J.V. Bertin wrote:
> True, even if there's probably very little point in disabling DBus on a 
> standard Unix/Linux set-up.
> 
> But indeed, a platform-agnostic option can still be included in the 
> options that will be flipped by a platform-specific option like 
> `APPLE_STANDALONE_BUNDLE` I've proposed in a patch for Marble.
> 
> To come back to what I suggested earlier: even if there were to be a KF5 
> framework that encapsulates DBus or "something more platform native" there 
> would still be a use-case for using DBus through that framework even on OS X 
> (or MS Windows). Projects like HomeBrew, MacPorts and Cygwin don't exist to 
> replace the native desktop, but to complement it; to provide an easy way to 
> install and maintain FOSS and provide a context in which those applications 
> can run as much as possible as they do on their native platform. That 
> evidently includes DBus, but not just so that Gnome apps can talk with other 
> Gnome apps and KDE apps with other KDE apps. I don't have any stats on this, 
> but I'd expect that a good many of the users of such projects use them not so 
> much for software development per se, but as tools for their actual work 
> (often in science and/or engineering, in my impression). That might very well 
> include using Gnome/GTk apps alongside KDE applications, and in that case 
> they'd proba
 bly expect  the same kind of interoperability as those apps would have on the 
other platforms they might use.
> IOW, I don't think a distribution system that aims to provide the best 
> possible context for the applications it carries can get around using DBus.
> 
> But this is probably not the best place for an in-depth discussion around 
> underlying principles; that should probably be done on a ML (and ideally 
> include a DBus dev or two).

i don't see a reason behind introducing a special cmake option other than code 
coverage (test dbus and dbus-free branches with the same qt): why one should 
want to disable dbus on a system where he/she has Qt with dbus?

can you explain this to me?

regarding homebrew, i repeat: by default it installs a precompiled version of 
Qt without dbus. if user wants dbus then he/she has to have homebrew recompile 
whole Qt (takes about 1 hour). and what if kde app doesn't need any IPC? that 
would just pollute his/her system with redundant stuff. how many gtk-based apps 
require dbus to run on windows and osx?


- Nick


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127896/#review95405
---


On May 12, 2016, 5:16 a.m., Nick Shaforostoff wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127896/
> ---
> 
> (Updated May 12, 2016, 5:16 a.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Frameworks, David Edmundson, 
> and Martin Gräßlin.
> 
> 
> Repository: kauth
> 
> 
> Description
> ---
> 
> this is the first patch to make kde frameworks build (and then work) without 
> dbus.
> 
> this will allow homebrew users use precompiled vanilla Qt to build kde apps 
> on osx. as dbus is not a common service in osx world, kde apps on osx should 
> use native means for interprocess communication instead -- this will make 
> them better citizens in osx ecosystem.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 48dc2d9 
>   autotests/BackendsManager.cpp 59675b3 
>   autotests/CMakeLists.txt b53d760 
>   autotests/HelperTest.cpp 8050a06 
>   src/CMakeLists.txt 1b6930d 
>   src/ConfigureChecks.cmake d46761a 
> 
> Diff: https://git.reviewboard.kde.org/r/127896/diff/
> 
> 
> Testing
> ---
> 
> compiles fine on osx, compiles fine on linux, tests on linux still pass.
> 
> 
> Thanks,
> 
> Nick Shaforostoff
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

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

[René J . V . Bertin]

> 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 kglobalaccel. The default is to require kglobalaccel, but if you 
> > knowingly specify "-DFORCE_DISABLE_KGLOBALACCEL=1" kglobalaccel is not 
> > required or searched for.

True, even if there's probably very little point in disabling DBus on a 
standard Unix/Linux set-up.

But indeed, a platform-agnostic option can still be included in the options 
that will be flipped by a platform-specific option like 
`APPLE_STANDALONE_BUNDLE` I've proposed in a patch for Marble.

To come back to what I suggested earlier: even if there were to be a KF5 
framework that encapsulates DBus or "something more platform native" there 
would still be a use-case for using DBus through that framework even on OS X 
(or MS Windows). Projects like HomeBrew, MacPorts and Cygwin don't exist to 
replace the native desktop, but to complement it; to provide an easy way to 
install and maintain FOSS and provide a context in which those applications can 
run as much as possible as they do on their native platform. That evidently 
includes DBus, but not just so that Gnome apps can talk with other Gnome apps 
and KDE apps with other KDE apps. I don't have any stats on this, but I'd 
expect that a good many of the users of such projects use them not so much for 
software development per se, but as tools for their actual work (often in 
science and/or engineering, in my impression). That might very well include 
using Gnome/GTk apps alongside KDE applications, and in that case they'd 
probably ex
 pect  the same kind of interoperability as those apps would have on the other 
platforms they might use.
IOW, I don't think a distribution system that aims to provide the best possible 
context for the applications it carries can get around using DBus.

But this is probably not the best place for an in-depth discussion around 
underlying principles; that should probably be done on a ML (and ideally 
include a DBus dev or two).


- René J.V.


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127896/#review95405
---


On May 12, 2016, 7:16 a.m., Nick Shaforostoff wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127896/
> ---
> 
> (Updated May 12, 2016, 7:16 a.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Frameworks, David Edmundson, 
> and Martin Gräßlin.
> 
> 
> Repository: kauth
> 
> 
> Description
> ---
> 
> this is the first patch to make kde frameworks build (and then work) without 
> dbus.
> 
> this will allow homebrew users use precompiled vanilla Qt to build kde apps 
> on osx. as dbus is not a common service in osx world, kde apps on osx should 
> use native means for interprocess communication instead -- this will make 
> them better citizens in osx ecosystem.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 48dc2d9 
>   autotests/BackendsManager.cpp 59675b3 
>   autotests/CMakeLists.txt b53d760 
>   autotests/HelperTest.cpp 8050a06 
>   src/CMakeLists.txt 1b6930d 
>   src/ConfigureChecks.cmake d46761a 
> 
> Diff: https://git.reviewboard.kde.org/r/127896/diff/
> 
> 
> Testing
> ---
> 
> compiles fine on osx, compiles fine on linux, tests on linux still pass.
> 
> 
> Thanks,
> 
> Nick Shaforostoff
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

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

[Kåre Särs]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127896/#review95405
---



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 
kglobalaccel. The default is to require kglobalaccel, but if you knowingly 
specify "-DFORCE_DISABLE_KGLOBALACCEL=1" kglobalaccel is not required or 
searched for.

- Kåre Särs


On May 12, 2016, 5:16 a.m., Nick Shaforostoff wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127896/
> ---
> 
> (Updated May 12, 2016, 5:16 a.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Frameworks, David Edmundson, 
> and Martin Gräßlin.
> 
> 
> Repository: kauth
> 
> 
> Description
> ---
> 
> this is the first patch to make kde frameworks build (and then work) without 
> dbus.
> 
> this will allow homebrew users use precompiled vanilla Qt to build kde apps 
> on osx. as dbus is not a common service in osx world, kde apps on osx should 
> use native means for interprocess communication instead -- this will make 
> them better citizens in osx ecosystem.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 48dc2d9 
>   autotests/BackendsManager.cpp 59675b3 
>   autotests/CMakeLists.txt b53d760 
>   autotests/HelperTest.cpp 8050a06 
>   src/CMakeLists.txt 1b6930d 
>   src/ConfigureChecks.cmake d46761a 
> 
> Diff: https://git.reviewboard.kde.org/r/127896/diff/
> 
> 
> Testing
> ---
> 
> compiles fine on osx, compiles fine on linux, tests on linux still pass.
> 
> 
> Thanks,
> 
> Nick Shaforostoff
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

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

[Martin Gräßlin]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127896/#review95404
---



Approach looks good to me, though I agree with Rene on making this a proper 
cmake option.

- Martin Gräßlin


On May 12, 2016, 7:16 a.m., Nick Shaforostoff wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127896/
> ---
> 
> (Updated May 12, 2016, 7:16 a.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Frameworks, David Edmundson, 
> and Martin Gräßlin.
> 
> 
> Repository: kauth
> 
> 
> Description
> ---
> 
> this is the first patch to make kde frameworks build (and then work) without 
> dbus.
> 
> this will allow homebrew users use precompiled vanilla Qt to build kde apps 
> on osx. as dbus is not a common service in osx world, kde apps on osx should 
> use native means for interprocess communication instead -- this will make 
> them better citizens in osx ecosystem.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 48dc2d9 
>   autotests/BackendsManager.cpp 59675b3 
>   autotests/CMakeLists.txt b53d760 
>   autotests/HelperTest.cpp 8050a06 
>   src/CMakeLists.txt 1b6930d 
>   src/ConfigureChecks.cmake d46761a 
> 
> Diff: https://git.reviewboard.kde.org/r/127896/diff/
> 
> 
> Testing
> ---
> 
> compiles fine on osx, compiles fine on linux, tests on linux still pass.
> 
> 
> Thanks,
> 
> Nick Shaforostoff
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

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

[René J . V . Bertin]

---
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 disabling DBus altogether 
on OS X!


CMakeLists.txt (lines 14 - 18)


Am I right that on OS X use of DBus is going to depend on whether or not Qt 
provides the QtDBus component? If so, shouldn't this be done on MS Windows too?

If that's *not* the right interpretation:
PLEASE introduce proper option variables for this kind of thing, for 
instance in ECM. Consider the overal picture; is this only about DBus or is 
this ultimately about building standalone app bundles? In other words, would it 
be possible to name that option variable appropriately to allow it to act as a 
switch for other, related build options?

This is all the more appropriate (and *polite*) if this is a convenience 
change for HomeBrew - why would such a change oblige other 
packaging/distribution systems to add and maintain unknown amounts of 
additional patches to undo it?!



autotests/BackendsManager.cpp (lines 26 - 30)


Again, double-checking: Is QT_NO_DBUS really going to be defined if the 
cmake system didn't do a `find_package(Qt5 ... DBus)`? IOW, is this change not 
going to introduce a build failure on systems where Qt does provide a DBus 
interface?



autotests/BackendsManager.cpp (lines 56 - 60)


Ditto, no risk of a build failure on systems where Qt does provide a DBus 
interface?



autotests/HelperTest.cpp (lines 27 - 31)


Ditto, no risk of a build failure on systems where Qt does provide a DBus 
interface?



autotests/HelperTest.cpp (lines 106 - 110)


Ditto, no risk of a build failure on systems where Qt does provide a DBus 
interface?



src/CMakeLists.txt 


Was this a redundant statement?


- René J.V. Bertin


On May 12, 2016, 7:16 a.m., Nick Shaforostoff wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127896/
> ---
> 
> (Updated May 12, 2016, 7:16 a.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Frameworks, David Edmundson, 
> and Martin Gräßlin.
> 
> 
> Repository: kauth
> 
> 
> Description
> ---
> 
> this is the first patch to make kde frameworks build (and then work) without 
> dbus.
> 
> this will allow homebrew users use precompiled vanilla Qt to build kde apps 
> on osx. as dbus is not a common service in osx world, kde apps on osx should 
> use native means for interprocess communication instead -- this will make 
> them better citizens in osx ecosystem.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 48dc2d9 
>   autotests/BackendsManager.cpp 59675b3 
>   autotests/CMakeLists.txt b53d760 
>   autotests/HelperTest.cpp 8050a06 
>   src/CMakeLists.txt 1b6930d 
>   src/ConfigureChecks.cmake d46761a 
> 
> Diff: https://git.reviewboard.kde.org/r/127896/diff/
> 
> 
> Testing
> ---
> 
> compiles fine on osx, compiles fine on linux, tests on linux still pass.
> 
> 
> Thanks,
> 
> Nick Shaforostoff
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

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

[René J . V . Bertin]

---
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, *inadvertently* ...

That "a bit harsh" statement was mine, and shouldn't have had someone else's 
picture attached to it.

My apologies for that (this cannot be changed/repaired, can it?)

- René J.V. Bertin


On May 12, 2016, 7:16 a.m., Nick Shaforostoff wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127896/
> ---
> 
> (Updated May 12, 2016, 7:16 a.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Frameworks, David Edmundson, 
> and Martin Gräßlin.
> 
> 
> Repository: kauth
> 
> 
> Description
> ---
> 
> this is the first patch to make kde frameworks build (and then work) without 
> dbus.
> 
> this will allow homebrew users use precompiled vanilla Qt to build kde apps 
> on osx. as dbus is not a common service in osx world, kde apps on osx should 
> use native means for interprocess communication instead -- this will make 
> them better citizens in osx ecosystem.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 48dc2d9 
>   autotests/BackendsManager.cpp 59675b3 
>   autotests/CMakeLists.txt b53d760 
>   autotests/HelperTest.cpp 8050a06 
>   src/CMakeLists.txt 1b6930d 
>   src/ConfigureChecks.cmake d46761a 
> 
> Diff: https://git.reviewboard.kde.org/r/127896/diff/
> 
> 
> Testing
> ---
> 
> compiles fine on osx, compiles fine on linux, tests on linux still pass.
> 
> 
> Thanks,
> 
> Nick Shaforostoff
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

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

[Nick Shaforostoff]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127896/
---

(Updated May 12, 2016, midnight)


Review request for KDE Frameworks, David Edmundson and Martin Gräßlin.


Changes
---

added KAUTH_HELPER_BACKEND_LIBS definition for compiling with 
-DKAUTH_HELPER_BACKEND_NAME=OSX cmake option


Repository: kauth


Description
---

this is the first patch to make kde frameworks build (and then work) without 
dbus.

this will allow homebrew users use precompiled vanilla Qt to build kde apps on 
osx. as dbus is not a common service in osx world, kde apps on osx should use 
native means for interprocess communication instead -- this will make them 
better citizens in osx ecosystem.


Diffs (updated)
-

  CMakeLists.txt 48dc2d9 
  autotests/BackendsManager.cpp 59675b3 
  autotests/CMakeLists.txt b53d760 
  autotests/HelperTest.cpp 8050a06 
  src/CMakeLists.txt 1b6930d 
  src/ConfigureChecks.cmake d46761a 

Diff: https://git.reviewboard.kde.org/r/127896/diff/


Testing
---

compiles fine on osx, compiles fine on linux, tests on linux still pass.


Thanks,

Nick Shaforostoff

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 127896: make dbus optional on osx: kauth

[Nick Shaforostoff]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127896/
---

Review request for KDE Frameworks, David Edmundson and Martin Gräßlin.


Repository: kauth


Description
---

this is the first patch to make kde frameworks build (and then work) without 
dbus.

this will allow homebrew users use precompiled vanilla Qt to build kde apps on 
osx. as dbus is not a common service in osx world, kde apps on osx should use 
native means for interprocess communication instead -- this will make them 
better citizens in osx ecosystem.


Diffs
-

  CMakeLists.txt 05e2874 
  autotests/BackendsManager.cpp 59675b3 
  autotests/CMakeLists.txt b53d760 
  autotests/HelperTest.cpp 8050a06 
  src/CMakeLists.txt 1b6930d 

Diff: https://git.reviewboard.kde.org/r/127896/diff/


Testing
---

compiles fine on osx, compiles fine on linux, tests on linux still pass.


Thanks,

Nick Shaforostoff

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel