On Monday 11 November 2013 11:13:37 David Faure wrote: > 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.
Yes, also it's kind of odd to not have a library hiding the implementation details of the actual access to the daemon... It's fragile. > 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. Yes, sounds good to me. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel