kdelibs/interfaces/khexedit

[Kevin Ottens]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20131111/13046d05/attachment.sig>