El Wednesday 14 October 2015, a les 00:07:10, Jaroslaw Staniek va escriure: > On 13 October 2015 at 23:22, Albert Astals Cid <aa...@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.
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. Albert _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
