From kwrite-devel Sun Nov 10 11:09:40 2013 From: Todd Date: Sun, 10 Nov 2013 11:09:40 +0000 To: kwrite-devel Subject: Re: KDE Frameworks 5 Switch, When, how, what? Message-Id: X-MARC-Message: https://marc.info/?l=kwrite-devel&m=138408181315082 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============4072836087519783415==" --===============4072836087519783415== Content-Type: multipart/alternative; boundary=047d7b6d878a1355b604ead0a892 --047d7b6d878a1355b604ead0a892 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Nov 10, 2013 at 11:39 AM, Dominik Haumann wrote: > On Saturday 09 November 2013 16:11:25 Todd wrote: > > On Nov 9, 2013 1:04 PM, "Christoph Cullmann" > 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. > > Yes, I understand the idea behind frameworks. However, ktexteditor is not listed in any of the frameworks planning documents as far as I was able to find so I wasn't sure how it fit into the overall frameworks picture. I am still unclear from your description, will ktexteditor continue to be shipped alongside kate and kwrite, or will it be split out so that can be built and installed separately from kate and kwrite? > 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 > :-) > > I am not the one doing the work, so my opinion means absolutely nothing, but there is another approach that some frameworks have been using that might be an option if you want to. In cases where a framework could be used as a low-tier component, but could also be useful as a higher-tier component, some frameworks have gone with the "both" approach, providing both a low-tier version that could be used by outside projects that want minimal framework dependencies, as well as a higher-tier convenience version that is easier to integrate into KDE applications. Although it may be infeasible or just too much work, one alternative approach would be to follow this model. Have two ktexteditor frameworks, a ktexteditor widget that has minimal KDE framework dependencies but requires more work to fully integrate into a Qt application, and a ktexteditor part that would be easier to integrate but would have dependencies on many more frameworks. That would allow the best of both worlds, but would likely require a major refactoring so may not be worth it. However, if it is going to be done, it may be easier to do it earlier rather than later, especially if you are concerned about binary compatibility. --047d7b6d878a1355b604ead0a892 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On S= un, Nov 10, 2013 at 11:39 AM, Dominik Haumann <dhaumann@kde.org> wrote:
On Saturday 09 November 20= 13 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 perhap= s we
> > should plan ahead how we want to go the 5.x road.
[...]
> > This is just a bit brainstorming to kick this t= opic 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 KT= extEditor are
already now included in the Kate git repository (for KDE 4.x, a copy is als= o
in kdelibs/interfaces/ktexteditor, but this is removed in KF5).

The idea behind frameworks is very well explained here:

=A0[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.


Yes, I understand the idea behind fram= eworks.=A0 However, ktexteditor is not listed in any of the frameworks plan= ning documents as far as I was able to find so I wasn't sure how it fit= into the overall frameworks picture.

I am still unclear from your description, will ktexteditor c= ontinue to be shipped alongside kate and kwrite, or will it be split out so= that can be built and installed separately from kate and kwrite?
=A0
But...

> It seems like there is some demand for an advanced text editor compone= nt
> for Qt, but up until now ktexteditor has been too tightly coupled to K= DE
> 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 Doc= ument
class, it becomes clear that KTextEditor relies on the KParts model. That i= s,
we use the XML GUI stuff to build our menus and to do the merge into other<= br> 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<= br> 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 :-= )


I am not the one doing the work, so my= opinion means absolutely nothing, but there is another approach that some = frameworks have been using that might be an option if you want to.=A0 In ca= ses where a framework could be used as a low-tier component, but could also= be useful as a higher-tier component, some frameworks have gone with the &= quot;both" approach, providing both a low-tier version that could be u= sed by outside projects that want minimal framework dependencies, as well a= s a higher-tier convenience version that is easier to integrate into KDE ap= plications.

Although it may be infeasible or just too much work, one alternative ap= proach would be to follow this model.=A0 Have two ktexteditor frameworks, a= ktexteditor widget that has minimal KDE framework dependencies but require= s more work to fully integrate into a Qt application, and a ktexteditor par= t that would be easier to integrate but would have dependencies on many mor= e frameworks.=A0 That would allow the best of both worlds, but would likely= require a major refactoring so may not be worth it.=A0 However, if it is g= oing to be done, it may be easier to do it earlier rather than later, espec= ially if you are concerned about binary compatibility.
--047d7b6d878a1355b604ead0a892-- --===============4072836087519783415== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KWrite-Devel mailing list KWrite-Devel@kde.org https://mail.kde.org/mailman/listinfo/kwrite-devel --===============4072836087519783415==--