kdelibs/interfaces/khexedit

[David Faure]

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, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5