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
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
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
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
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
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
---
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
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
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.
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.
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
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
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
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
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
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
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
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
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
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
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
> 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
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
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
>
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
---
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
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
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
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
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
---
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
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,
>
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)
>
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
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
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
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
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
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
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
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125628/#review86874
---
src/kdecore/ktempdir.cpp
---
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
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
43 matches
Mail list logo