Policy for Dependencies

[Christoph Cullmann]

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 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.
> 
> That's not what i said.
> 
>> 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.
> 
> I hope you're not suggesting I'm against the 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?
> 
> dbus here was just an example, as was phonon.
> 
> What i was trying to say is that having a global ECM_BUILD_FOR_OSX_APPBUNDLE
> in a framework is a bad idea since it makes the decision about the things i
> want to include in the framework binary, you either get all the features or
> none.
> 
> I should be able to decide if i want to go the extra mile adding features to
> my bundle or not in feature by feature basis, by either making things optional
> directly, or via a cmake switch.
I am all with Albert here, such a global switch that "randomly" deactivates features
globally just because e.g. I was to lame to build phonon on some OS is bad.

Both the "one global switch to make stuff optional" or "multiple switches to make stuff optional"
is a much better route to got that enables people to pick the things they want to
have on any OS.

Lets see what David thinks about all that.

Greetings
Christoph

-- 
----------------------------- Dr.-Ing. Christoph Cullmann ---------
AbsInt Angewandte Informatik GmbH      Email: cullmann at AbsInt.com
Science Park 1                         Tel:   +49-681-38360-22
66123 Saarbrücken                      Fax:   +49-681-38360-20
GERMANY                                WWW:   http://www.AbsInt.com
--------------------------------------------------------------------
Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234