[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-devel
Subject: Re: What is our plan for Qt6 and QXmlPatterns?
From: Helio Chissini de Castro <helio () kde ! org>
Date: 2021-10-28 6:32:45
Message-ID: CAKPiqoF1PYYCzA6c1gTfcU6BvV=wfoKtP3TbtWxKf8b_z-uu7w () mail ! gmail ! com
[Download RAW message or body]
Hi Albert
Can i raise the questions on all valid possible solutions ?
- Maintain qxmlpattern on our side
- Move to libxslt
- Move away from Xml
The first one is easy from the point of view of applications, but we don't
know how much maintenance towards qt6 will be considering.
The second one is a little more complex from the point of view of
applications, some for buildsystem as well, but then we will use a library
that is already proven everywhere and don't need to maintain and can
consider API stable enough.
The third one, more unlikely but valid, is to understand why we are using
XmlPatterns and if we can't replace it with something more modern for the
"6" interaction of frameworks/plasma. Is some new development and will
introduce a lot of new things to thought, but then, still a valid
possibility.
[]'s
On Thu, Oct 28, 2021 at 12:31 AM Albert Astals Cid <aacid@kde.org> wrote:
> QXmlPatterns has been deprecated for a long time and the current plan is
> that there will no Qt6 release of it.
>
> We use it in quite some places
>
>
> https://lxr.kde.org/search?%21v=kf5-qt5&_filestring=CMakeLists.txt&_string=XmlPatterns
>
> For those that don't want to click the link
> artikulate
> cantor
> digikam
> gcompris
> Maybe not?
> https://invent.kde.org/education/gcompris/-/merge_requests/89
> kbibtex
> kdav
> kdav2
> kig
> ktouch
> rocs
> syntax-highlighting
> kdepim-runtime
> kipi-plugins
> massif-visualizer
> Maybe not?
> https://invent.kde.org/sdk/massif-visualizer/-/merge_requests/3
>
>
> It's not a whole lot of apps, but it's a considerable number.
>
> The suggested solution by The Qt Project seems to be migrate to something
> like libxslt.
>
> Has anyone have any experience with that?
>
> Could we create some kind of wrapper so we would not have to port all
> those apps one by one?
>
> Another potential solution is us "adopting" QtXmlPatterns and porting it
> to Qt6, the code is said to be a bit of a nightmare and basically
> unmaintainable, that's why The Qt Project doesn't want to have a Qt6
> version, but given we don't have commitments like commercial support for
> our things, we could probably get away with a "we did this for ourselves,
> you should really not use it" statement.
>
> Any other ideas?
>
> Cheers,
> Albert
>
>
>
>
>
[Attachment #3 (text/html)]
<div dir="ltr"><div class="gmail_default" \
style="font-family:verdana,sans-serif;font-size:large">Hi Albert</div><div \
class="gmail_default" \
style="font-family:verdana,sans-serif;font-size:large"><br></div><div \
class="gmail_default" style="font-family:verdana,sans-serif;font-size:large">Can i \
raise the questions on all valid possible solutions ?</div><div class="gmail_default" \
style="font-family:verdana,sans-serif;font-size:large"><br></div><div \
class="gmail_default" style="font-family:verdana,sans-serif;font-size:large">- \
Maintain qxmlpattern on our side</div><div class="gmail_default" \
style="font-family:verdana,sans-serif;font-size:large">- Move to libxslt</div><div \
class="gmail_default" style="font-family:verdana,sans-serif;font-size:large">- Move \
away from Xml</div><div class="gmail_default" \
style="font-family:verdana,sans-serif;font-size:large"><br></div><div \
class="gmail_default" style="font-family:verdana,sans-serif;font-size:large">The \
first one is easy from the point of view of applications, but we don't know how \
much maintenance towards qt6 will be considering.</div><div class="gmail_default" \
style="font-family:verdana,sans-serif;font-size:large"><br></div><div \
class="gmail_default" style="font-family:verdana,sans-serif;font-size:large">The \
second one is a little more complex from the point of view of applications, some for \
buildsystem as well, but then we will use a library that is already proven everywhere \
and don't need to maintain and can consider API stable enough. </div><div \
class="gmail_default" \
style="font-family:verdana,sans-serif;font-size:large"><br></div><div \
class="gmail_default" style="font-family:verdana,sans-serif;font-size:large">The \
third one, more unlikely but valid, is to understand why we are using XmlPatterns \
and if we can't replace it with something more modern for the "6" \
interaction of frameworks/plasma. Is some new development and will introduce a lot \
of new things to thought, but then, still a valid possibility.</div><div \
class="gmail_default" \
style="font-family:verdana,sans-serif;font-size:large"><br></div><div \
class="gmail_default" \
style="font-family:verdana,sans-serif;font-size:large">[]'s</div><div \
class="gmail_default" \
style="font-family:verdana,sans-serif;font-size:large"><br></div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 28, 2021 at 12:31 \
AM Albert Astals Cid <<a href="mailto:aacid@kde.org">aacid@kde.org</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">QXmlPatterns has been \
deprecated for a long time and the current plan is that there will no Qt6 release of \
it.<br> <br>
We use it in quite some places<br>
<br>
<a href="https://lxr.kde.org/search?%21v=kf5-qt5&_filestring=CMakeLists.txt&_string=XmlPatterns" \
rel="noreferrer" target="_blank">https://lxr.kde.org/search?%21v=kf5-qt5&_filestring=CMakeLists.txt&_string=XmlPatterns</a><br>
<br>
For those that don't want to click the link<br>
artikulate<br>
cantor<br>
digikam<br>
gcompris<br>
Maybe not? <a \
href="https://invent.kde.org/education/gcompris/-/merge_requests/89" rel="noreferrer" \
target="_blank">https://invent.kde.org/education/gcompris/-/merge_requests/89</a><br> \
kbibtex<br> kdav<br>
kdav2<br>
kig<br>
ktouch<br>
rocs<br>
syntax-highlighting<br>
kdepim-runtime<br>
kipi-plugins<br>
massif-visualizer<br>
Maybe not? <a \
href="https://invent.kde.org/sdk/massif-visualizer/-/merge_requests/3" \
rel="noreferrer" target="_blank">https://invent.kde.org/sdk/massif-visualizer/-/merge_requests/3</a><br>
<br>
<br>
It's not a whole lot of apps, but it's a considerable number.<br>
<br>
The suggested solution by The Qt Project seems to be migrate to something like \
libxslt.<br> <br>
Has anyone have any experience with that? <br>
<br>
Could we create some kind of wrapper so we would not have to port all those apps one \
by one?<br> <br>
Another potential solution is us "adopting" QtXmlPatterns and porting it to \
Qt6, the code is said to be a bit of a nightmare and basically unmaintainable, \
that's why The Qt Project doesn't want to have a Qt6 version, but given we \
don't have commitments like commercial support for our things, we could probably \
get away with a "we did this for ourselves, you should really not use it" \
statement.<br> <br>
Any other ideas?<br>
<br>
Cheers,<br>
Albert<br>
<br>
<br>
<br>
<br>
</blockquote></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic