Re: Policy for Dependencies

On Tuesday, October 13, 2015 8:42:43 AM CEST Christoph Cullmann wrote: > Hi, thanks for raising this topic. I think it's very important that we have a general strategy for frameworks and not have thousands of micro-fixes in various frameworks. > 1) "Normal" deployment like we do in on Linux =>

Re: Policy for Dependencies

Hello, On Thursday 15 October 2015 02:04:45 Aleix Pol wrote: > 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 >

Re: Policy for Dependencies

On 2015-10-19 17:53, Christoph Cullmann wrote: On Sunday, 18 October 2015 14:45:43 BST David Faure wrote: 2) A global switch "everything that can be optional, is now optional" sounds strange to me too. If it's optional, it's optional. (The description for the suggested

Re: Policy for Dependencies

Hi, > On Sunday, 18 October 2015 14:45:43 BST David Faure wrote: >> On Wednesday 14 October 2015 00:33:17 Christoph Cullmann wrote: >> > Lets see what David thinks about all that. >> >> First: thanks everyone for waiting for my input, I appreciate that (I'm just >> one more voice though, no

Re: Policy for Dependencies

On Sunday, 18 October 2015 14:45:43 BST David Faure wrote: > On Wednesday 14 October 2015 00:33:17 Christoph Cullmann wrote: > > Lets see what David thinks about all that. > > First: thanks everyone for waiting for my input, I appreciate that (I'm just > one more voice though, no dictatorship

Re: Policy for Dependencies

Hi, I have now all my patches in frameworks to build some KWrite/Kate application bundle that doesn't instantly crash (and windows builds seem to be nicer, too, without that many problems to locate assets). My last patch missing makes still stuff optional:

Re: Policy for Dependencies

On Wednesday 14 October 2015 00:33:17 Christoph Cullmann wrote: > > Lets see what David thinks about all that. First: thanks everyone for waiting for my input, I appreciate that (I'm just one more voice though, no dictatorship here). The various global switches that have been suggested had

Re: Policy for Dependencies

On 14 October 2015 at 20:55, Boudewijn Rempt wrote: > 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

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

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

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

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

Re: Policy for Dependencies

Hey, On Tue, Oct 13, 2015 at 6:20 PM, Christoph Cullmann wrote: > > I hope I didn't upset anybody, just got a bit frustrated by the current > state of > the art. Alone how many patches for all our stuff are floating around in > the net > to make it somehow buildable instead

Re: Policy for Dependencies

On Tuesday, October 13, 2015 8:42:43 AM CEST Christoph Cullmann wrote: > Hi, thanks for raising this topic. I think it's very important that we have a general strategy for frameworks and not have thousands of micro-fixes in various frameworks. > 1) "Normal" deployment like we do in on Linux =>

Policy for Dependencies

Hi, in my quest to get Kate working on Mac (and Windows), I needed to patch some frameworks to have less required dependencies. e.g. doctools is a hassle on Windows and phonon is a hassle on both win/mac (if you don't require audio, like most applications won't) Now there is a bit of

Re: Policy for Dependencies

Hi, > On Tuesday, October 13, 2015 8:42:43 AM CEST Christoph Cullmann wrote: >> Hi, > > thanks for raising this topic. I think it's very important that we have a > general strategy for frameworks and not have thousands of micro-fixes in > various frameworks. ;=) > >> 1) "Normal" deployment

Re: Policy for Dependencies

Hi, >> Ok, after the reasonable criticisms of making the sound stuff optional in >> knotifications per default: >> >> Could we have some ECM switch like (name is just an example): >> >> option(KDE_ENABLE_MINIMAL_DEPENDENCIES "Will switch as many dependencies >> from required to optional as

Re: Policy for Dependencies

Hi, different take on that below: > Hi, > >> On Tuesday, October 13, 2015 8:42:43 AM CEST Christoph Cullmann wrote: >>> Hi, >> >> thanks for raising this topic. I think it's very important that we have a >> general strategy for frameworks and not have thousands of micro-fixes in >> various

Re: Policy for Dependencies

On Tue, Oct 13, 2015 at 2:20 PM, Christoph Cullmann wrote: > Hi, > > different take on that below: > >> Hi, >> >>> On Tuesday, October 13, 2015 8:42:43 AM CEST Christoph Cullmann wrote: Hi, >>> >>> thanks for raising this topic. I think it's very important that we have a

Re: Policy for Dependencies

Hi, >> Ok, after the reasonable criticisms of making the sound stuff optional in >> knotifications per default: >> >> Could we have some ECM switch like (name is just an example): >> >> option(KDE_ENABLE_MINIMAL_DEPENDENCIES "Will switch as many dependencies from >> required to optional as

Re: Policy for Dependencies

On Tuesday, October 13, 2015 2:20:31 PM CEST Christoph Cullmann wrote: > Hi, > > different take on that below: > > Hi, > > > >> On Tuesday, October 13, 2015 8:42:43 AM CEST Christoph Cullmann wrote: > >>> Hi, > >> > >> thanks for raising this topic. I think it's very important that we have a >

Re: Policy for Dependencies

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 that nobody looks at the output of

Re: Policy for Dependencies

On 2015-10-13, Martin Graesslin wrote: > 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 >

Re: Policy for Dependencies

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 - build-time depending on xml/docbook processing tools to just have core KF5 libs built -

Re: Policy for Dependencies

El Tuesday 13 October 2015, a les 08:55:27, Martin Graesslin va escriure: > On Tuesday, October 13, 2015 8:42:43 AM CEST Christoph Cullmann wrote: > > Hi, > > thanks for raising this topic. I think it's very important that we have a > general strategy for frameworks and not have thousands of

Re: Policy for Dependencies

El Tuesday 13 October 2015, a les 14:20:31, Christoph Cullmann va escriure: > Hi, > > different take on that below: > > Hi, > > > >> On Tuesday, October 13, 2015 8:42:43 AM CEST Christoph Cullmann wrote: > >>> Hi, > >> > >> thanks for raising this topic. I think it's very important that we have

Re: Policy for Dependencies

El Tuesday 13 October 2015, a les 23:59:33, Christoph Cullmann va escriure: > Hi, > > >> Ok, after the reasonable criticisms of making the sound stuff optional in > >> knotifications per default: > >> > >> Could we have some ECM switch like (name is just an example): > >> > >>

Re: Policy for Dependencies

Hi, >> Ok, after the reasonable criticisms of making the sound stuff optional in >> knotifications per default: >> >> Could we have some ECM switch like (name is just an example): >> >> option(KDE_ENABLE_MINIMAL_DEPENDENCIES "Will switch as many dependencies >> from required to optional as

Re: Policy for Dependencies

Hi, > On 2015-10-13, Martin Graesslin wrote: >> 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

Re: Policy for Dependencies

On 13 October 2015 at 23:22, Albert Astals Cid wrote: > > El Tuesday 13 October 2015, a les 08:55:27, Martin Graesslin va escriure: > > On Tuesday, October 13, 2015 8:42:43 AM CEST Christoph Cullmann wrote: > > > Hi, > > > > thanks for raising this topic. I think it's very

Re: Policy for Dependencies

Albert Astals Cid ha scritto: > El Wednesday 14 October 2015, a les 00:07:10, Jaroslaw Staniek va escriure: >> >> Your view may be different, more workspace-related, your definition of >> portability may be different too. I am looking at code that uses KF5 >> as a Qt code in the first place. Qt

Re: Policy for Dependencies

Hi, > El Tuesday 13 October 2015, a les 23:59:33, Christoph Cullmann va escriure: >> Hi, >> >> >> Ok, after the reasonable criticisms of making the sound stuff optional in >> >> knotifications per default: >> >> >> >> Could we have some ECM switch like (name is just an example): >> >> >> >>

Re: Policy for Dependencies

El Wednesday 14 October 2015, a les 00:07:10, Jaroslaw Staniek va escriure: > On 13 October 2015 at 23:22, Albert Astals Cid wrote: > > El Tuesday 13 October 2015, a les 08:55:27, Martin Graesslin va escriure: > > > On Tuesday, October 13, 2015 8:42:43 AM CEST Christoph Cullmann

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. >> >> Albert, >> From the fact that some foreign solution (dbus is foreign to OSX and >> for that