I see, and agree. So the way forward with kspeech would be to make it it's own framework. then at some point turn the header/dbus interface into a library that can hide the implementation details of using the dbus interface directly, right? Something like libkspeech.so that has a class/namespace to interact with the speech dbus interface itself.
BR, Jeremy On Mon, Nov 11, 2013 at 4:33 AM, Kevin Ottens <er...@kde.org> wrote: > 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 > > > _______________________________________________ > Kde-frameworks-devel mailing list > Kde-frameworks-devel@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel > _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel