[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: Todd <toddrjen () gmail ! com>
Date: 2013-11-10 11:09:40
Message-ID: CAFpSVpKdnEgFJ-XVipNo8AX4pHqhXj+st-H5UXGH1YuXXJ5p0A () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Sun, Nov 10, 2013 at 11:39 AM, Dominik Haumann <dhaumann@kde.org> wrote:
> 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.
>
>
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.
[Attachment #5 (text/html)]
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Nov 10, 2013 at 11:39 AM, \
Dominik Haumann <span dir="ltr"><<a href="mailto:dhaumann@kde.org" \
target="_blank">dhaumann@kde.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div class="im">On Saturday 09 November 2013 16:11:25 Todd wrote:<br> > On Nov \
9, 2013 1:04 PM, "Christoph Cullmann" <<a \
href="mailto:cullmann@absint.com">cullmann@absint.com</a>> wrote:<br> > > Hi,<br>
> ><br>
> > KDE Frameworks 5 gets more traction in the last months and perhaps we<br>
> > should plan ahead how we want to go the 5.x road.<br>
</div>[...]<br>
<div class="im">> > This is just a bit brainstorming to kick this topic off, comments /<br>
> > changes are welcome :P<br>
><br>
> > Greetings<br>
> > Christoph<br>
><br>
> Are there plans to split ktexteditor into its own framework?<br>
<br>
</div>Yes, that's the whole point of this frameworks initiative. The KTextEditor are<br>
already now included in the Kate git repository (for KDE 4.x, a copy is also<br>
in kdelibs/interfaces/ktexteditor, but this is removed in KF5).<br>
<br>
The idea behind frameworks is very well explained here:<br>
<br>
[1] <a href="http://dot.kde.org/2013/09/25/frameworks-5" \
target="_blank">http://dot.kde.org/2013/09/25/frameworks-5</a><br> <br>
KTextEditor along with its implementation Kate Part will be just another<br>
module in the frameworks initiative.<br>
<br></blockquote><div><br></div><div>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.<br>
<br></div><div>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?<br></div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> But...<br>
<div class="im"><br>
> It seems like there is some demand for an advanced text editor component<br>
> for Qt, but up until now ktexteditor has been too tightly coupled to KDE<br>
> and Kate to usable for this purpose.<br>
><br>
> However, if ktexteditor was split into its own framework, which can be<br>
> built independently Kate and kwrite and had only the minimum necessary<br>
> dependencies on other frameworks, it might be a very attractive option.<br>
<br>
</div>...if you look at the KTextEditor interfaces, for instance at the Document<br>
class, it becomes clear that KTextEditor relies on the KParts model. That is,<br>
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.<br>
<br>
Now looking at [1] again, KParts itself is probably a "Tier 3 Solution".<br>
If we stick with KParts, the KTextEditor interfaces + Kate Part is also a<br>
Tier 3 Solution, meaning that Kate Part has all the little dependencies on<br>
KParts, Xml Gui, KService and what now. Just like now.<br>
<br>
So from this perspective, if you are a Qt application and want to use the<br>
KTextEditor interfaces, you would need to pull in all that stuff again.<br>
<br>
In other words, the answer is: Yes, KTextEditor will be a frameworks module,<br>
but so high in the stack that we again need all the dependencies.<br>
<br>
Does that make sense so far?<br>
<br>
<br>
This is currently as I see the initial migration to frameworks 5.<br>
Other opinions or discussions about possible other solutions are welcome :-)<br>
<br></blockquote><div><br></div><div>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.<br>
<br>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.<br>
</div></div></div></div>
_______________________________________________
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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic