[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwrite-devel
Subject:    Re: KDE Frameworks 5 Switch, When, how, what?
From:       Dominik Haumann <dhaumann () kde ! org>
Date:       2013-11-10 10:39:09
Message-ID: 7065417.yjYDZ6LVtS () eriador
[Download RAW message or body]

On Saturday 09 November 2013 16:11:25 Todd wrote:
> On Nov 9, 2013 1:04 PM, "Christoph Cullmann" <cullmann@absint.com> wrote:
> > Hi,
> > 
> > KDE Frameworks 5 gets more traction in the last months and perhaps we
> > should plan ahead how we want to go the 5.x road.
[...]
> > This is just a bit brainstorming to kick this topic off, comments /
> > changes are welcome :P
> 
> > Greetings
> > Christoph
> 
> Are there plans to split ktexteditor into its own framework?

Yes, that's the whole point of this frameworks initiative. The KTextEditor are 
already now included in the Kate git repository (for KDE 4.x, a copy is also 
in kdelibs/interfaces/ktexteditor, but this is removed in KF5).

The idea behind frameworks is very well explained here:

 [1] http://dot.kde.org/2013/09/25/frameworks-5

KTextEditor along with its implementation Kate Part will be just another 
module in the frameworks initiative.

But...

> It seems like there is some demand for an advanced text editor component
> for Qt, but up until now ktexteditor has been too tightly coupled to KDE
> and Kate to usable for this purpose.
>
> However, if ktexteditor was split into its own framework, which can be
> built independently Kate and kwrite and had only the minimum necessary
> dependencies on other frameworks, it might be a very attractive option.

...if you look at the KTextEditor interfaces, for instance at the Document 
class, it becomes clear that KTextEditor relies on the KParts model. That is, 
we use the XML GUI stuff to build our menus and to do the merge into other 
applications. This, currently, is the core of Kate Part.

Now looking at [1] again, KParts itself is probably a "Tier 3 Solution".
If we stick with KParts, the KTextEditor interfaces + Kate Part is also a
Tier 3 Solution, meaning that Kate Part has all the little dependencies on
KParts, Xml Gui, KService and what now. Just like now.

So from this perspective, if you are a Qt application and want to use the 
KTextEditor interfaces, you would need to pull in all that stuff again.

In other words, the answer is: Yes, KTextEditor will be a frameworks module, 
but so high in the stack that we again need all the dependencies.

Does that make sense so far?


This is currently as I see the initial migration to frameworks 5.
Other opinions or discussions about possible other solutions are welcome :-)

Greetings,
Dominik
_______________________________________________
KWrite-Devel mailing list
KWrite-Devel@kde.org
https://mail.kde.org/mailman/listinfo/kwrite-devel
[prev in list] [next in list] [prev in thread] [next in thread]