kdelibs/interfaces/khexedit

[Jeremy Whiting]

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 <ervin at 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 at kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>