Policy for Dependencies

[Jaroslaw Staniek]

On 13 October 2015 at 23:22, Albert Astals Cid <aacid at kde.org> 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 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 => just installing it with
> > > all features if possible. 2) "Application Bundles/Installer" like we will
> > > have to do it on Win/Mac and 3rdparty Linux people will need to do.
> > >
> > > I think the easiest solution is to make stuff optional. That will avoid
> > > ugly "if (WIN OR APPLE OR ANDROID)".. hacks in CMake and allow people to
> > > still build stuff with that deps on that operating systems if really
> > > wanted.
> > Given from the no-X11 fixes I think that we should avoid all if (WIN OR
> > APPLE) as that:
> > a) is hard to maintain
> > b) doesn't scale
> > c) not testable for the devs working on Linux
> >
> > Given that it should be feature based and we should make as much usage of
> > the built in CMake features we have. I really like the approach we have now
> > found for X11 on OSX: disable certain find modules at a global level.
> >
> > I think that is something which could be applied for more things. Control
> > through global ECM settings. This could if we don't want to have global
> > changes also through convenient command switches:
> >
> > e.g. cmake -DECM_BUILD_FOR_OSX_APPBUNDLE
> >
> > which then implies e.g. no phonon and no dbus and ...
>
> 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 matter Windows) is available on these OSes one cannot
conclude that having option not to include/use them in my OSX/Windows
app makes no sense.

These OSes have own solutions for sound system and desktop IPC.

Just like explorer.exe shell is perfectly valid feature delivered by a
FOSS project wine on Linux. This does not mean I have to base file
browsing experience for my Linux users on explorer.exe.

And have you actually read what the APPBUNDLE would mean? An OS with
dozen of instances of dbus, each installed by one app, fighting for
user's attention is a quite possible scenario.

Albert, if you want dbus-based workspace, there are OSes where it's
native. I bet you can use them.
We're talking about portable code, not portable runtimes (like Java,
.NET, Chrome) that feel foreign/superficial on every OS.

Let's drop the desktop/workspace hat when talking about frameworks.
Otherwise it's hard to hope that people will think about employing KF5
to the outside world tasks -- numerous dependencies still remind them
the "kdelibs" times of a kitchen sink approach. That wouldn't be
honest to KF5 contributors because of man-years of great work
invested.

Please don't stop maturing of KF5.

Christoph doing a real native port, presents a rare use case close to
real outside world.

PS: Accept the fact that there are OSes without *rc files but
registry. Quite close, this includes Linux+GNOME. Most probably even
more users will uses/will use KDE software on such OSes than on the
traditional one. I am convinced there are more Qt apps on these other
OSes than under Linux.

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 does not ignore design decisions
of supported OSes, why would KF5 do this?
-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek