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: cullm...@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 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
