--===============3128942497499447807== Content-Type: multipart/alternative; boundary=001a11c1e3dc95fc3a04eabfe94d --001a11c1e3dc95fc3a04eabfe94d Content-Type: text/plain; charset=ISO-8859-1 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. > > We have a lot of "cleanups" and "fixups" listed for the KTextEditor interfaces we want to do for > the 5.x release and until now I think we have no clear plan when to go for this. > > I think Kate/KatePart are at the moment in a relative good state for the 4.x line and not that much stuff is missing > that we actually need to implement in 4.x (beside perhaps some plugin enhancements or bugfixes). > > Perhaps we should draft some small timeline for the future when we want to go to switch the main focus > on porting + cleaning for 5.0. > > We should coordinate a bit with the KDevelop guys, not sure how their plans for 5.x are, either. > > I would propose for Kate, to create some "frameworks" branch in December, in which the idea is to > > a) first get it compiling with KDE 5 Frameworks + Qt 5.2 > b) then cleanup and fix the stuff in the interfaces > > This "frameworks" branch would have no BC/SC requirements until we arrive in the 5.0 Beta phase I think. > > "master" should stay KDE 4.x until the last 4.xx release is done and then we can switch that over. > > All stuff that goes into master after the frameworks branch is there must be synced to frameworks by > the people doing the change, there won't be an auto-merge by me or someone else I think. > > 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? 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. --001a11c1e3dc95fc3a04eabfe94d Content-Type: text/html; charset=ISO-8859-1

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.
>
> We have a lot of "cleanups" and "fixups" listed for the KTextEditor interfaces we want to do for
> the 5.x release and until now I think we have no clear plan when to go for this.
>
> I think Kate/KatePart are at the moment in a relative good state for the 4.x line and not that much stuff is missing
> that we actually need to implement in 4.x (beside perhaps some plugin enhancements or bugfixes).
>
> Perhaps we should draft some small timeline for the future when we want to go to switch the main focus
> on porting + cleaning for 5.0.
>
> We should coordinate a bit with the KDevelop guys, not sure how their plans for 5.x are, either.
>
> I would propose for Kate, to create some "frameworks" branch in December, in which the idea is to
>
> a) first get it compiling with KDE 5 Frameworks + Qt 5.2
> b) then cleanup and fix the stuff in the interfaces
>
> This "frameworks" branch would have no BC/SC requirements until we arrive in the 5.0 Beta phase I think.
>
> "master" should stay KDE 4.x until the last 4.xx release is done and then we can switch that over.
>
> All stuff that goes into master after the frameworks branch is there must be synced to frameworks by
> the people doing the change, there won't be an auto-merge by me or someone else I think.
>
> 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?

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.

--001a11c1e3dc95fc3a04eabfe94d-- --===============3128942497499447807== 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 --===============3128942497499447807==--