On Sunday 10 November 2013 15:28:27 Kevin Ottens wrote: > On Sunday 10 November 2013 11:15:58 Dominik Haumann wrote: > > On Sunday 10 November 2013 09:47:41 David Faure wrote: > > > On Sunday 10 November 2013 04:32:12 Friedrich W. H. Kossebau wrote: > > > > So from my point of view, especially given the idea of KF5, I see no > > > > more need for interfaces/khexedit. Rather do I see the Okteta libs > > > > themselves (the core ones for simple widget things) one day being > > > > added > > > > to KF5, now that things are modular :) > > > > > > Yep, makes sense. > > > > > > I'll just delete interfaces/khexedit then, thanks for the input. > > > > Btw, this is basically the same solution as we take with KTextEditor: The > > KTextEditor interfaces are not part of some other module anymore. Instead > > they are directly shipped with Kate Part for KF5. This makes sense for the > > simple reason that there is no other KTextEditor implementation than Kate > > Part (for 10 years now). From this perspective. The same basically holds > > for Okteta imo: If you need a hex editor component, just state that as > > dependency at compile time and all is fine. > > > > So as I see it, removing interfaces/khexedit is the right way to go :-) > > Actually that's probably the way to go for the other interfaces too... Like > the kspeech one.
Well, it's a bit different. okteta provides a library that people can link to directly. kspeech, on the other hand, is a daemon with a dbus interface. The files in interfaces/kspeech are the dbus interface and a simple header to define enum values. In a sense *that* is the library (but it doesn't even need a .so). What I mean is, *that* is the "framework" that needs to be found at compilation time. But OK, the idea of frameworks is to bundle the compile-time bits with the runtime bits, so what you're saying is, a kspeech framework should include both this stuff and the daemon. We could still start the framework with the compile-time bits for now, and add the daemon later on, much like we plan to do with a lot of kde-runtime after the kdelibs splitting. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
