Re: Policy for Dependencies

On Tue, 13 Oct 2015, Albert Astals Cid wrote: I disagree, phonon and dbus are available on OSX and could be made to work so having a ECM_BUILD_FOR_OSX_APPBUNDLE that disables perfectly valid features doesn't make sense to me. But what if those things don't add any feature to a particularly

Re: Policy for Dependencies

On Tue, 13 Oct 2015, Christoph Cullmann wrote: I think we must accept, that on neither Windows nor Mac we will have all dependencies available and that for many applications not all features are needed. There is no "packagers" for that operating systems, you need to provide the stuff you use

Re: Policy for Dependencies

On Wed, Oct 14, 2015 at 10:44 AM, Boudewijn Rempt wrote: > On Tue, 13 Oct 2015, Albert Astals Cid wrote: > > I disagree, phonon and dbus are available on OSX and could be made to work >> so having a ECM_BUILD_FOR_OSX_APPBUNDLE that disables perfectly valid >> features doesn't

Re: Policy for Dependencies

Hi, > I disagree, phonon and dbus are available on OSX and could be made to work so > having a ECM_BUILD_FOR_OSX_APPBUNDLE that disables perfectly valid features > doesn't make sense to me. > > But what if those things don't add any feature to a particularly app? There's > nothing that phonon or

Jenkins-kde-ci: kcoreaddons master stable-kf5-qt5 » Linux,gcc - Build # 55 - Fixed!

GENERAL INFO BUILD SUCCESS Build URL: https://build.kde.org/job/kcoreaddons%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/55/ Project: PLATFORM=Linux,compiler=gcc Date of build: Wed, 14 Oct 2015 18:06:27 + Build duration: 4 min 33 sec CHANGE SET Revision

Jenkins-kde-ci: kcoreaddons master stable-kf5-qt5 » Linux,gcc - Build # 55 - Fixed!

GENERAL INFO BUILD SUCCESS Build URL: https://build.kde.org/job/kcoreaddons%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/55/ Project: PLATFORM=Linux,compiler=gcc Date of build: Wed, 14 Oct 2015 18:06:27 + Build duration: 4 min 33 sec CHANGE SET Revision

Review Request 125638: Avoid kio crashs if no dbus server is running

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

Re: Policy for Dependencies

El Wednesday 14 October 2015, a les 16:44:12, Boudewijn Rempt va escriure: > On Tue, 13 Oct 2015, Albert Astals Cid wrote: > > I disagree, phonon and dbus are available on OSX and could be made to work > > so having a ECM_BUILD_FOR_OSX_APPBUNDLE that disables perfectly valid > > features doesn't

Re: Policy for Dependencies

On Wed, 14 Oct 2015, Martin Klapetek wrote: Fwiw, KNotification+Phonon is used for KDialog sounds if frameworkintegration is present (iirc). So in theory, it should play a sound in Krita/Kate if you eg. close the window with unsaved content. If that adds anything to your app, I can't say.

Re: Policy for Dependencies

On Wed, Oct 14, 2015 at 1:27 PM, Boudewijn Rempt wrote: > On Wed, 14 Oct 2015, Martin Klapetek wrote: > > Fwiw, KNotification+Phonon is used for KDialog sounds if >> frameworkintegration >> is present (iirc). So in theory, it should play a sound in Krita/Kate if >> you eg.

Re: Policy for Dependencies

On Wed, Oct 14, 2015 at 1:38 PM, Christoph Cullmann wrote: > > Given that lot opposition was here for a 5 lines change which does break > nothing > if packagers don't skrew up. > Not to be disrespectful, but history has proven that the assumption above unfortunately doesn't

Jenkins-kde-ci: kcoreaddons master kf5-qt5 » Linux,gcc - Build # 59 - Fixed!

GENERAL INFO BUILD SUCCESS Build URL: https://build.kde.org/job/kcoreaddons%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/59/ Project: PLATFORM=Linux,compiler=gcc Date of build: Wed, 14 Oct 2015 18:06:26 + Build duration: 4 min 15 sec CHANGE SET Revision

Jenkins-kde-ci: kcoreaddons master kf5-qt5 » Linux,gcc - Build # 59 - Fixed!

GENERAL INFO BUILD SUCCESS Build URL: https://build.kde.org/job/kcoreaddons%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/59/ Project: PLATFORM=Linux,compiler=gcc Date of build: Wed, 14 Oct 2015 18:06:26 + Build duration: 4 min 15 sec CHANGE SET Revision

Re: Policy for Dependencies

Hi, > Fwiw, KNotification+Phonon is used for KDialog sounds if frameworkintegration > is present (iirc). So in theory, it should play a sound in Krita/Kate if you > eg. > close > the window with unsaved content. If that adds anything to your app, I can't > say. > > > ^That's supposed to be

Re: Policy for Dependencies

On Wed, 14 Oct 2015, Martin Klapetek wrote: But then it makes me wonder if you actually need KNotifications altogether. I'm not aware of anyone actually testing KNotificaitons on win/mac and I personally wouldn't guarantee it works at all on !linux. Same for Kate - do you actually need

Re: phonon hassle to build WAS: Re: Policy for Dependencies

On Wed, Oct 14, 2015 at 8:47 AM, Christoph Cullmann wrote: >> On Tue, Oct 13, 2015 at 8:42 AM, Christoph Cullmann >> wrote: >>> phonon is a hassle on both win/mac (if you don't require audio, like most >>> applications won't) >> >> Oo >> >> explain

Re: phonon hassle to build WAS: Re: Policy for Dependencies

On Wed, Oct 14, 2015 at 8:58 AM, Christoph Cullmann wrote: > Hi, > >> On Wed, Oct 14, 2015 at 8:47 AM, Christoph Cullmann >> wrote: On Tue, Oct 13, 2015 at 8:42 AM, Christoph Cullmann wrote: > phonon is a hassle on

phonon hassle to build WAS: Re: Policy for Dependencies

On Tue, Oct 13, 2015 at 8:42 AM, Christoph Cullmann wrote: > phonon is a hassle on both win/mac (if you don't require audio, like most > applications won't) Oo explain please? ___ Kde-frameworks-devel mailing list

Re: phonon hassle to build WAS: Re: Policy for Dependencies

Hi, > On Wed, Oct 14, 2015 at 8:47 AM, Christoph Cullmann > wrote: >>> On Tue, Oct 13, 2015 at 8:42 AM, Christoph Cullmann >>> wrote: phonon is a hassle on both win/mac (if you don't require audio, like most applications won't) >>> >>> Oo

Re: phonon hassle to build WAS: Re: Policy for Dependencies

Hi, >>> but why would you want to build a backend if you need no sound anyway? >> Thats the point, if I don't build a backend, I don't need phonon and I can >> save building + shipping it with just making phonon optional for >> knotifications, >> which internally already is build in a way to

Re: Policy for Dependencies

On Tuesday, October 13, 2015 10:07:18 PM CEST Jaroslaw Staniek wrote: > Hi, > Just wanted to say I'd like to minimize dependencies for Kexi on Windows > too, among other things. > > With my realistic hat on, risky ideas are like: > - depending on kdecoration to just have default icons I hope

Re: phonon hassle to build WAS: Re: Policy for Dependencies

> On Tue, Oct 13, 2015 at 8:42 AM, Christoph Cullmann > wrote: >> phonon is a hassle on both win/mac (if you don't require audio, like most >> applications won't) > > Oo > > explain please? Hi, to build phonon with an usable backends is work on mac and win and e.g. Kate

Re: phonon hassle to build WAS: Re: Policy for Dependencies

On Wed, Oct 14, 2015 at 9:11 AM, Christoph Cullmann wrote: > Hi, > but why would you want to build a backend if you need no sound anyway? >>> Thats the point, if I don't build a backend, I don't need phonon and I can >>> save building + shipping it with just making

Re: Policy for Dependencies

Hi, > Well, sure, stuff can break. However, without changes like this, KDE's > Frameworks libraries are _not fit for purpose_. These libraries _can not > be used_ by the intended user group, that is application developers, > except for the tiny minority that only targets Linux, and only cares >

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

Review Request 125640: Remove special handling when service is already registered

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

Re: Policy for Dependencies

On Wed, 14 Oct 2015, Martin Klapetek wrote: I have to agree with Harald here though, I would also expect the frameworks to be bunch of pre-built dlls you just install system-wide and build on top of that, not create your own custom builds of everything, for every app with different features

Re: Policy for Dependencies

Hello, On Wednesday 14 October 2015 21:20:33 Christoph Cullmann wrote: > Therefore my goal for frameworks is to make them actually as easy usable > for people in that situation. We advertise that a lot everywhere but at the > moment that is just not true beside for really simple stuff like

Re: Policy for Dependencies

On Wed, 14 Oct 2015, Martin Klapetek wrote: On Wed, Oct 14, 2015 at 1:38 PM, Christoph Cullmann wrote: Given that lot opposition was here for a 5 lines change which does break nothing if packagers don't skrew up. Not to be disrespectful, but history has

Re: Policy for Dependencies

I'd like to weigh in a bit here too. I agree with Boud and Christoph, most users (developers of applications) of KF5 that aren't KDE community members will be building the frameworks themselves. At my last job we built Qt ourselves on all the platforms we targetted and shipped shared libraries

Review Request 125641: Allow PAM unlocking of a running wallet

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

Re: Policy for Dependencies

On Wed, Oct 14, 2015 at 2:55 PM, Boudewijn Rempt wrote: > > Well, sure, stuff can break. However, without changes like this, KDE's > Frameworks libraries are _not fit for purpose_. These libraries _can not > be used_ by the intended user group, that is application developers, >

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

Hi, > 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) >

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] [OS X] adding a link module to all KF5 targets

Hi, >> I am already quiet annoyed to see we actually can turn on X11 on Mac, Qt's >> own >> X11 backend is not available >> per default anyway, which sense makes that? > > Qt's X11 backend builds just fine except for a few details that should be easy > enough to address. > > Choice is good but

Jenkins-kde-ci: kcoreaddons master kf5-qt5 » Linux,gcc - Build # 58 - Unstable!

GENERAL INFO BUILD UNSTABLE Build URL: https://build.kde.org/job/kcoreaddons%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/58/ Project: PLATFORM=Linux,compiler=gcc Date of build: Wed, 14 Oct 2015 10:24:35 + Build duration: 2 min 28 sec CHANGE SET Revision

Re: Policy for Dependencies

On Wed, Oct 14, 2015 at 10:28 PM, Kevin Ottens wrote: > Hello, > > On Wednesday 14 October 2015 21:20:33 Christoph Cullmann wrote: >> Therefore my goal for frameworks is to make them actually as easy usable >> for people in that situation. We advertise that a lot everywhere but at

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

Jenkins-kde-ci: kcoreaddons master stable-kf5-qt5 » Linux,gcc - Build # 54 - Unstable!

GENERAL INFO BUILD UNSTABLE Build URL: https://build.kde.org/job/kcoreaddons%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/54/ Project: PLATFORM=Linux,compiler=gcc Date of build: Wed, 14 Oct 2015 10:24:35 + Build duration: 1 min 57 sec CHANGE SET Revision

Re: Policy for Dependencies

On 2015-10-13 16:54, Christoph Cullmann wrote: Hi, I'm not sure whether it's the best solution. The problem you try to fix with it is distros breaking packaging. I agree with Martin K that this is a huge problem and that it will happen - since the automation of packages I also experienced

Re: Review Request 125628: KTempDir: Make sense out of s_umask initialization

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125628/#review86874 --- src/kdecore/ktempdir.cpp

Re: Review Request 125628: KTempDir: Make sense out of s_umask initialization

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125628/ --- (Updated Oct. 15, 2015, 1:33 a.m.) Status -- This change has been

Re: Policy for Dependencies

Hi, - Aleix Pol schrieb: > On We > Would it make sense then to define as part of the tier only the > mandatory dependencies? > > Then the variable could be, instead of what Christoph proposed, > something like KDE_ENFORCE_ALL_FRAMEWORKS. For my usecase that wont help, as i