Re: Banning QNetworkAccessManager

[Ben Cooksley]

On Mon, Feb 3, 2020 at 7:42 AM Volker Krause  wrote:
>
> I agree on the problem of QNAM's default, see also https://conf.kde.org/en/
> akademy2019/public/events/135 on that subject.
>
> On Saturday, 1 February 2020 23:24:14 CET Ben Cooksley wrote:
> [...]
> > Prior to now, i've taken the approach of advertising that
> > QNetworkAccessManager is broken and needs a flag set within
> > applications when used, however unfortunately this seems to have been
> > an ineffective approach and cases of broken behaviour continue to
> > appear (despite this brokeness being known about and advertised since
> > back in the Qt 4.x series when this class was introduced)
> >
> > Therefore, given the Qt Project is unlikely to change their position
> > on this, I would like to propose the following:
>
> The Qt Project is actually in favor of changing at least the redirection
> default to exactly what we want it to be.
> https://codereview.qt-project.org/c/qt/qtbase/+/273175 has the change, and got
> approval both by Lars and one of the maintainers. It is merely stuck in
> dealing with the unit test fallout in Qt's CI that somebody has to take care
> of. Doesn't immediately help us of course, but claiming Qt is unwilling to
> change this is simply wrong.
>
> > 1) That effective immediately, QNetworkAccessManager and it's children
> > classes be banned and prohibited within KDE software, to be enforced
> > by server side hooks.
> > 2) That we fork QNetworkAccessManager and the associated classes
> > within the appropriate Framework (to be determined), where the
> > defective behaviour can then be corrected.
>
> While this might solve the redirection problem, it brings us yet another then
> unmaintained HTTP implementation next to the one in KIO, which is a far bigger
> problem long term. We need less of those, not more.
>
> To address the problem of people not using the correct defaults, I did propose
> a much less extreme approach in the above mentioned talk at Akademy, namely
> having a KNetworkAccessManager as a sub-class of QNAM in a low-tier frameworks
> that essentially just enables redirects and HSTS. QNAM's implementation isn't
> the problem after all, the defaults are.
>
> Commit hooks warning about QNAM usage might still be a good idea, but as a
> warning only. Hard blocking QNAM-using code would block at least three repos I
> spend a lot of time on currently, none of which even talks to KDE servers.
>
> If you need to take more drastic measures against code not doing this
> correctly regardless, you can do that my dropping the server-side workarounds.
> Yes, that would break the affected application possibly, but at least it would
> not cause massive collateral damage for the people using this correctly.
>
> It would also help to know where specifically we have that problem, so we can
> actually solve it, and so we can figure out why we failed to fix this there
> earlier.

Just bringing this up again - it seems we've not had much movement on
this aside from the Wiki page.

Examining that Qt merge request, it not only is targeted at just Qt
6.x, it also hasn't had any movement since the start of October 2019 -
4 months ago.
Given that we are going to be on Qt 5.x for some time, that merge
request can't be considered to be the 'fix' for this issue.

We need a solution that will ensure software released today doesn't
cause us pain in several years time, because as I illustrated in an
earlier email to this thread, software has a habit of remaining in use
for an extremely long amount of time (August 2014 being the release
date of the Marble versions in question hitting that old URL).

The easiest path forward is to simply ban QNetworkAccessManager.

>
> Regards,
> Volker

Regards,
Ben

D27152: Introduce FilesystemEntry class

[David Hallas]

hallas updated this revision to Diff 75961.
hallas marked 17 inline comments as done.
hallas added a comment.


  Updated patch with review comments

REPOSITORY
  R245 Solid

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27152?vs=74977=75961

BRANCH
  introduce_filesystem_entry

REVISION DETAIL
  https://phabricator.kde.org/D27152

AFFECTED FILES
  autotests/CMakeLists.txt
  autotests/filesystem_entry_test.cpp
  autotests/filesystem_entry_test.h
  autotests/filesystem_type_test.cpp
  autotests/filesystem_type_test.h
  src/solid/devices/backends/fstab/CMakeLists.txt
  src/solid/devices/backends/fstab/filesystem_entry.cpp
  src/solid/devices/backends/fstab/filesystem_entry.h
  src/solid/devices/backends/fstab/filesystem_type.cpp
  src/solid/devices/backends/fstab/filesystem_type.h
  src/solid/devices/backends/fstab/fstabdevice.cpp
  src/solid/devices/backends/fstab/fstabhandling.cpp
  src/solid/devices/backends/fstab/fstabhandling.h

To: hallas, #frameworks, bruns, meven
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

KDE CI: Frameworks » kio » kf5-qt5 SUSEQt5.12 - Build # 435 - Still Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks/job/kio/job/kf5-qt5%20SUSEQt5.12/435/
 Project:
kf5-qt5 SUSEQt5.12
 Date of build:
Wed, 19 Feb 2020 04:45:01 +
 Build duration:
19 min and counting
   BUILD ARTIFACTS
  acc/KF5KIO-5.68.0.xmllogs/KF5KIO/5.68.0/log.txt
   JUnit Tests
  Name: (root) Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)Name: projectroot Failed: 1 test(s), Passed: 52 test(s), Skipped: 0 test(s), Total: 53 test(s)Failed: projectroot.autotests.kiofilewidgets_knewfilemenutestName: projectroot.autotests Failed: 0 test(s), Passed: 6 test(s), Skipped: 0 test(s), Total: 6 test(s)Name: projectroot.src.ioslaves.trash Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)Name: projectroot.src.kpasswdserver Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)
   Cobertura Report
  
   Project Coverage Summary
  
   Name
  PackagesFilesClassesLinesConditionalsCobertura Coverage Report67%
(24/36)67%
(270/406)67%
(270/406)56%
(34795/62085)40%
(17678/43872)Coverage Breakdown by Package
Name
   FilesClassesLinesConditionalsautotests100%
(58/58)100%
(58/58)96%
(9726/10183)47%
(4540/9636)autotests.http100%
(5/5)100%
(5/5)99%
(580/581)68%
(108/160)autotests.kcookiejar100%
(1/1)100%
(1/1)91%
(179/197)72%
(49/68)src100%
(1/1)100%
(1/1)86%
(6/7)67%
(4/6)src.core88%
(104/118)88%
(104/118)60%
(8716/14618)51%
(4509/8853)src.core.kssl100%
(1/1)100%
(1/1)40%
(35/88)50%
(3/6)src.filewidgets68%
(26/38)68%
(26/38)56%
(4661/8329)43%
(2069/4812)src.gui100%
(2/2)100%
(2/2)94%
(102/108)74%
(49/66)src.ioslaves.file100%
(7/7)100%
(7/7)54%
(680/1269)39%
(390/1000)src.ioslaves.file.kauth0%
(0/2)0%
(0/2)0%
(0/168)0%
(0/89)src.ioslaves.ftp100%
(2/2)100%
(2/2)47%
(645/1372)37%
(525/1420)src.ioslaves.help0%
(0/5)0%
(0/5)0%
(0/247)0%
(0/148)src.ioslaves.http88%
(7/8)88%
(7/8)42%
(1796/4288)36%
(1309/3636)src.ioslaves.http.kcookiejar40%
(2/5)40%
(2/5)47%
(632/1331)56%
(578/1029)src.ioslaves.remote100%
(2/2)100%
(2/2)27%
(73/267)8%
(14/184)src.ioslaves.remote.kdedmodule0%
(0/2)0%
 

KDE CI: Frameworks » kio » kf5-qt5 SUSEQt5.13 - Build # 310 - Still Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks/job/kio/job/kf5-qt5%20SUSEQt5.13/310/
 Project:
kf5-qt5 SUSEQt5.13
 Date of build:
Wed, 19 Feb 2020 04:45:01 +
 Build duration:
8 min 17 sec and counting
   BUILD ARTIFACTS
  acc/KF5KIO-5.68.0.xmllogs/KF5KIO/5.68.0/log.txt
   JUnit Tests
  Name: (root) Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)Name: projectroot Failed: 1 test(s), Passed: 52 test(s), Skipped: 0 test(s), Total: 53 test(s)Failed: projectroot.autotests.kiofilewidgets_knewfilemenutestName: projectroot.autotests Failed: 0 test(s), Passed: 6 test(s), Skipped: 0 test(s), Total: 6 test(s)Name: projectroot.src.ioslaves.trash Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)Name: projectroot.src.kpasswdserver Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)
   Cobertura Report
  
   Project Coverage Summary
  
   Name
  PackagesFilesClassesLinesConditionalsCobertura Coverage Report67%
(24/36)67%
(270/406)67%
(270/406)56%
(34800/62086)40%
(17691/43868)Coverage Breakdown by Package
Name
   FilesClassesLinesConditionalsautotests100%
(58/58)100%
(58/58)96%
(9726/10183)47%
(4544/9636)autotests.http100%
(5/5)100%
(5/5)99%
(580/581)68%
(108/160)autotests.kcookiejar100%
(1/1)100%
(1/1)91%
(179/197)72%
(49/68)src100%
(1/1)100%
(1/1)86%
(6/7)67%
(4/6)src.core88%
(104/118)88%
(104/118)60%
(8717/14618)51%
(4515/8853)src.core.kssl100%
(1/1)100%
(1/1)40%
(35/88)50%
(3/6)src.filewidgets68%
(26/38)68%
(26/38)56%
(4666/8329)43%
(2070/4808)src.gui100%
(2/2)100%
(2/2)94%
(102/108)74%
(49/66)src.ioslaves.file100%
(7/7)100%
(7/7)54%
(680/1269)39%
(390/1000)src.ioslaves.file.kauth0%
(0/2)0%
(0/2)0%
(0/168)0%
(0/89)src.ioslaves.ftp100%
(2/2)100%
(2/2)47%
(645/1372)37%
(525/1420)src.ioslaves.help0%
(0/5)0%
(0/5)0%
(0/247)0%
(0/148)src.ioslaves.http88%
(7/8)88%
(7/8)42%
(1796/4288)36%
(1309/3636)src.ioslaves.http.kcookiejar40%
(2/5)40%
(2/5)47%
(632/1331)56%
(578/1029)src.ioslaves.remote100%
(2/2)100%
(2/2)27%
(73/267)8%
(14/184)src.ioslaves.remote.kdedmodule0%
(0/2)0%
   

KDE CI: Frameworks » kio » kf5-qt5 FreeBSDQt5.13 - Build # 302 - Still Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks/job/kio/job/kf5-qt5%20FreeBSDQt5.13/302/
 Project:
kf5-qt5 FreeBSDQt5.13
 Date of build:
Wed, 19 Feb 2020 04:45:01 +
 Build duration:
7 min 15 sec and counting
   JUnit Tests
  Name: projectroot Failed: 5 test(s), Passed: 47 test(s), Skipped: 0 test(s), Total: 52 test(s)Failed: projectroot.autotests.kiocore_jobtestFailed: projectroot.autotests.kiocore_kmountpointtestFailed: projectroot.autotests.kiofilewidgets_knewfilemenutestFailed: projectroot.autotests.kiowidgets_kdirlistertestFailed: projectroot.autotests.kiowidgets_kdirmodeltestName: projectroot.autotests Failed: 0 test(s), Passed: 6 test(s), Skipped: 0 test(s), Total: 6 test(s)Name: projectroot.src.ioslaves.trash Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)Name: projectroot.src.kpasswdserver Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)

D27334: Fix pri file: have qmake name of QtGui as dep, do not fail with CamelCase includes

[Aleix Pol Gonzalez]

apol accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R280 Prison

BRANCH
  prifixesreview

REVISION DETAIL
  https://phabricator.kde.org/D27334

To: kossebau, svuorela, vkrause, apol
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D27430: [PATCH] General update for CartoCSS syntax highlighting

[Lukas Sommer]

sommer added a comment.


  Yep.
  
  Here comes an updated version for test.mss:
  
/* kate: hl CartoCSS
   This file contains some content coming from
   https://github.com/gravitystorm/openstreetmap-carto
   with CC0 license. This file is just for testing
   katepart highlighting engine.
   */

#world {
  // this syntax
  polygon-opacity: 50%; // the parameter “polygon-opacity” gets the value 
0.5 (expressed in %)
  // is equivalent to
  polygon-opacity: 0.5;
}

/*
Variables behave similar to C macros
*/
@lsdjkf: @sdlfkj; // this variable gets defined by the value of another 
variable
@admin-boundaries: #ac46ac; // this variable gets defined by a color value
@way_pixels: "([way_area]*pow(4,@zoom)/2450574)"; // A rather complex 
variable. [way_area] marks a data field. @zoom is a special runtime value 
(inspite of the @ it has nothing to do with ordinary variables)

/* This is
a multiline comment.
*/

// A single line comment
#admin-low-zoom[zoom < 11],  // A single line comment
#admin-mid-zoom[zoom >= 11][zoom < 13] {
  [admin_level = '2'], // Within filters, data fields like “admin_level” 
are referended without extra [] brackets.
  [admin_level = '3'] { // These data fields are rendered by default in 
dark blue, while the data field within expression strings are rendered by 
default in light blue.
[zoom >= 4] {
  background/line-color: white; // symbolizer named “background”
  background/line-width: 0.6; // symbolizer named “background”
  line-color: @admin-boundaries; // default symbolizer (without name)
  name: [test]; // simplified reference to the data field “test”
  name: "[test]"; // another reference to the data field “test”, this 
time within an expression string (by default orange)
  name: "([way_area]*pow(4,@zoom)/2450574)"; // a rather complex 
expression string that will do some math
  name: "'Value: '[test]"; // A verbatim string (by default red) as 
part of an expression string
  name: '"Value: "[test]'; // " and ' are interchangable. The outer is 
always the expression string and the inner the verbatim string.
}
  }
  [admin_level = '4'] { // The string '4' is red because at this position 
it will be interpreted as a verbatim string, not as an expression string.
[zoom >= 4] {
  line-dasharray: 4,3; // parameter “line-dasharray” gets as value a 
list of two integers
  line-clip: false;  // parameter “line-clip” gets as value a boolean
}
  }
  comp-op: darken; // parameter “comp-op” gets as value “darken”.
}

.nature-reserve-boundaries { // .nature-reserve-boudaries references a 
class, which is similar to a layer like #building-text, so both are rendered 
the same way
  [way_pixels > 100][zoom >= 7] { // Here zoom is a keyword with results in 
a special filter. However, all other values are interpreted as data fields.
[zoom < 10] {
  ::fill { // The :: syntax defined “attachments” (a sort of sub-layer 
within normal layers). So “fill” is rendered by default in the same style like 
layer names and class names (but this can be customized).
opacity: 0.05;
// various styles to define colors (all except the color function 
are rendered the same way):
polygon-fill: white;
polygon-fill: #ff;
polygon-fill: #fff;
polygon-fill: rgba(255,255,255,1); // define a color by a speciel 
function
polygon-fill: #; // invalid color value
text-placement: interior; // all unknown values are hightlighted as 
named values.
  }
}
  }
}

REPOSITORY
  R216 Syntax Highlighting

REVISION DETAIL
  https://phabricator.kde.org/D27430

To: sommer, #framework_syntax_highlighting
Cc: cullmann, kwrite-devel, kde-frameworks-devel, rrosch, LeGast00n, cblack, 
gennad, GB_2, bmortimer, domson, michaelh, genethomas, ngraham, bruns, 
demsking, vkrause, sars, dhaumann

Re: 2 kirigami fixes for a point release

[Nate Graham]

On 2/18/20 1:37 PM, Albert Astals Cid wrote:

I still don't see why this is a problem, as said Plasma depends on a myriad of 
libraries that are building each with their own release model, most probably 
with no bugfix releases at all either.


The "we don't control the whole stack" argument does not apply to parts 
of the stack that we do control. Improvement is possible even when 
perfection is not.




Incidentally what happens is that those libraries are not buggy, and it seems 
the Plasma-facing parts of KF5 are, well, let's make them not be.


Agreed. Everyone wants less buggy releases.

However "less buggy releases" does not fully solve the problem for LTS 
distros that freeze their KF version. Without point releases of the 
version they freeze on, we are unable to ship fixes for regressions that 
do sneak in, and we are unable to ship fixes for old or longstanding 
issues that we find a way to fix later. We can do both of these things 
with Plasma. We cannot do either with Frameworks. That's the problem.


Ultimately I think we need to decide whether we want to fully support 
the Plasma LTS or can it. Right now we're in this awkward position where 
we can hand packagers tarballs with bugfix point releases of Plasma, but 
not Frameworks. Ultimately this means that there's a class of bug that 
just doesn't get fixed in the distros with LTS Plasma, which in the end 
makes us look bad.


Nate

Re: 2 kirigami fixes for a point release

[Nate Graham]

On 2/18/20 2:13 PM, Luca Beltrame wrote:

In data martedì 18 febbraio 2020 19:26:21 CET, Nate Graham ha scritto:


Neon is already an OS, whether or not you want to admit it. It's
installed from an ISO. A hardware vendor (Slimbook) is shipping it on


Erm, where did I say that in my reply? ;)  I merely say that going "Neon or
else unsupported" is a very downstream-hostile attitude,


...And where did I say that in my reply? ;) I think we should absolutely 
continue to support all downstreams, not just Neon; that would be crazy! 
:) This is in fact why I'm advocating for an LTS Frameworks release to 
accompany the Plasma LTS release: to better support our non-Neon 
downstreams who want to freeze on the Plasma LTS releases. Right now 
we're pushing the job of backporting bugfixes to Frameworks onto them, 
rather than making it easy by just giving them tarballs. We can argue 
about what packagers should do, but the best way to get them to do that 
is to make it easy for them. :)




(Neon suffers from the same "LTS problem" for everything that's not KDE-made
software, FTR, but that's not the issue I want to raise here)


Indeed, and that's the reason why I'm happy with Tumbleweed. I'm quite 
on board with the seemingly prevailing opinion that discrete LTS 
releases amount to a broken, defective model. It's just that for the 
time being we have a product explicitly catering to distros using that 
broken, defective model. It just seems like an awkward situation that 
should be addressed one way or another, not left in tension indefinitely.


Nate

Re: 2 kirigami fixes for a point release

[Luca Beltrame]

In data martedì 18 febbraio 2020 19:26:21 CET, Nate Graham ha scritto:

> Neon is already an OS, whether or not you want to admit it. It's
> installed from an ISO. A hardware vendor (Slimbook) is shipping it on

Erm, where did I say that in my reply? ;)  I merely say that going "Neon or 
else unsupported" is a very downstream-hostile attitude, already seen with 
other software ("my way or the highway" in these cases) such as Audacity or 
Anki (the latter being one of the most downstream-hostile projects I've ever 
known). 

(Neon suffers from the same "LTS problem" for everything that's not KDE-made 
software, FTR, but that's not the issue I want to raise here)


-- 
Luca Beltrame - KDE Forums team
GPG key ID: A29D259B

signature.asc
Description: This is a digitally signed message part.

Re: 2 kirigami fixes for a point release

[Albert Astals Cid]

El dimarts, 18 de febrer de 2020, a les 4:03:05 CET, Nate Graham va escriure:
> On 2020-02-16 14:43, Albert Astals Cid wrote:
> > Maybe i explain myself wrongly, i'm not blaming distros at all.
> > 
> > They made a decision, we/I may agree with them or not, that's *my/our* 
> > problem, what I was disagreeing is to us having to do extra work because 
> > someone elses (the distros) decision.
> 
> We already do this: it's called the Plasma LTS product. :-) It's been 
> specifically created to cater to various distros' desires for an 
> extended-support product they can ship to users of their own LTS releases.
> 
> But yes, I can also agree with more tests, better stability, moving to 
> GitLab so tests are run before merging, etc. I think we can all agree 
> with that.
> 
> However all the autotests in the world will not resolve the fundamental 
> incompatibility between the Plasma LTS product, which is built around 
> the release model of extended, ongoing bugfix releases, and Frameworks, 
> which is built around a rolling release model with no bugfix releases at 
> all.

I still don't see why this is a problem, as said Plasma depends on a myriad of 
libraries that are building each with their own release model, most probably 
with no bugfix releases at all either.

Incidentally what happens is that those libraries are not buggy, and it seems 
the Plasma-facing parts of KF5 are, well, let's make them not be.

Cheers,
  Albert

D27486: Add FreeCAD FCMacro extension to the python highlighting definition

[Miklos Marton]

martonmiklos created this revision.
martonmiklos added a reviewer: Framework: Syntax Highlighting.
Herald added projects: Kate, Frameworks.
Herald added subscribers: kde-frameworks-devel, kwrite-devel.
martonmiklos requested review of this revision.

REVISION SUMMARY
  Add FreeCAD FCMacro extension to the python highlighting definition.
  They are python scripts see:
  https://www.freecadweb.org/wiki/Macros

TEST PLAN
  Open an FCMacro file and it should have correct highlighting.

REPOSITORY
  R216 Syntax Highlighting

REVISION DETAIL
  https://phabricator.kde.org/D27486

AFFECTED FILES
  data/syntax/python.xml

To: martonmiklos, #framework_syntax_highlighting
Cc: kwrite-devel, kde-frameworks-devel, rrosch, LeGast00n, cblack, GB_2, 
domson, michaelh, ngraham, bruns, demsking, cullmann, sars, dhaumann

Re: 2 kirigami fixes for a point release

[Nate Graham]

On 2/16/20 2:55 PM, Friedrich W. H. Kossebau wrote:

Yes, this has been questioned a few times. Also seeing Plasma LTS used
together with a non-LTS Qt is a bit strange.
But somehow it seems there has not been enough pain for those using the Plasma
LTS to change something. Possibly because distributions simply backport
important bug fixes for KF themselves, kind of maintaining their own KF LTS
version of the KF version they pinpointed to when they froze the ingredients
to their OS. Because they are used to do this for other projects as well, and
so miss this could be done in cooperation with upstream.


There has been pain. This thread mentions a number of examples, and 
There were quite a few for the last 5.12 LTS too. But more generally, 
the pain is baked into Frameworks due to the lack of any bugfix 
releases. For example Kubuntu 18.04 shipped with the Plasma 5.12 LTS and 
Frameworks 5.44. That Plasma version has continued to receive bugfix 
point releases since then. But the Frameworks product has not, and so 
users have now missed out on two years worth of bugfixes. I don't know 
about openSUSE, but I know that Kubuntu does not have the resources to 
backport individual KF bugfixes--I repeatedly requested this as I 
identified them and none ever got backported. But they do ship point 
releases for Plasma, so they could ship point releases for an LTS 
Frameworks version.




IMHO distributions using Plasma LTS, Plasma team & other stakeholders should
team up here and maintain a matching LTS branch of Frameworks together at the
central KDE repos together. Well, and a version also satisfying other clients
of KF, like non-workspace applications from KDE.

It's not a reason to change normal KF release cycle.


I like that idea. So perhaps we could say that the KF version which 
happens to be the dependency for a Plasma LTS release could have bugfix 
releases? Would that be reasonable?



Nate

Re: 2 kirigami fixes for a point release

[Nate Graham]

On 2/16/20 2:55 PM, Friedrich W. H. Kossebau wrote:

Yes, this has been questioned a few times. Also seeing Plasma LTS used
together with a non-LTS Qt is a bit strange.
But somehow it seems there has not been enough pain for those using the Plasma
LTS to change something. Possibly because distributions simply backport
important bug fixes for KF themselves, kind of maintaining their own KF LTS
version of the KF version they pinpointed to when they froze the ingredients
to their OS. Because they are used to do this for other projects as well, and
so miss this could be done in cooperation with upstream.


There has been pain. This thread mentions a number of examples, and 
There were quite a few for the last 5.12 LTS too. But more generally, 
the pain is baked into Frameworks due to the lack of any bugfix 
releases. For example Kubuntu 18.04 shipped with the Plasma 5.12 LTS and 
Frameworks 5.44. That Plasma version has continued to receive bugfix 
point releases since then. But the Frameworks product has not, and so 
users have now missed out on two years worth of bugfixes. I don't know 
about openSUSE, but I know that Kubuntu does not have the resources to 
backport individual KF bugfixes--I repeatedly requested this as I 
identified them and none ever got backported. But they do ship point 
releases for Plasma, so they could ship point releases for an LTS 
Frameworks version.




IMHO distributions using Plasma LTS, Plasma team & other stakeholders should
team up here and maintain a matching LTS branch of Frameworks together at the
central KDE repos together. Well, and a version also satisfying other clients
of KF, like non-workspace applications from KDE.

It's not a reason to change normal KF release cycle.


I like that idea. So perhaps we could say that the KF version which 
happens to be the dependency for a Plasma LTS release could have bugfix 
releases? Would that be reasonable?



Nate

Re: 2 kirigami fixes for a point release

[Nate Graham]

On 2/17/20 11:08 PM, Luca Beltrame wrote:

In data martedì 18 febbraio 2020 04:03:05 CET, Nate Graham ha scritto:


think KDE software should be presented to users. Basically, we
acknowledge that Neon is already an actual OS--the "KDE OS"--and we


Please don't suggest such downstream-hostile solutions, in particular because
this failing is entirely upstream. We have already plenty in FOSS, I don't
want KDE to be yet another community that "adopts" them.

"We messed up so let's make things our way" is not an acceptable approach.


Neon is already an OS, whether or not you want to admit it. It's 
installed from an ISO. A hardware vendor (Slimbook) is shipping it on 
laptops that people can and do buy. My wife has it installed on her 
computer. It's an OS as much as any other Ubuntu-derived distro can be 
considered an OS.


I actually happen to use openSUSE Tumbleweed myself instead of Neon for 
a variety of reasons, and I'm happy with it. I'm not saying "Neon is an 
OS!" because I think everyone should immediately switch to it and stop 
using other distros. There's room in the universe of KDE distros for one 
more that happens to be a first-party product--as evidenced by the fact 
that Neon has existed for four years and the whole world hasn't come 
tumbling down. I mean, Microsoft got into the PC hardware business in 
competition with Dell, HP, Toshiba, et al, and it didn't destroy their 
business. Far from it: the new entries from Microsoft spurred everyone 
else to improve their own offerings, broadly lifting the quality of PC 
hardware for everyone.


Nate

D27083: [PC2]Give Label integer width.

[George Vogiatzis]

gvgeo added a comment.


  > Also, why is only PC2 affected?
  
  Just checked again, apparently made a mistake. All the labels are affected.

REPOSITORY
  R242 Plasma Framework (Library)

REVISION DETAIL
  https://phabricator.kde.org/D27083

To: gvgeo, #plasma, #vdg, ndavis, davidedmundson
Cc: davidedmundson, kde-frameworks-devel, Orage, LeGast00n, The-Feren-OS-Dev, 
cblack, jraleigh, zachus, fbampaloukas, GB_2, ragreen, michaelh, ZrenBot, 
ngraham, bruns, alexeymin, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, ahiemstra, mart

D27459: Port QLinkedList which is deprecated in qt5.15

[Laurent Montel]

This revision was automatically updated to reflect the committed changes.
Closed by commit R263:c5863523f3aa: Port QLinkedList which is deprecated in 
qt5.15 (authored by mlaurent).

REPOSITORY
  R263 KXmlGui

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27459?vs=75830=75936

REVISION DETAIL
  https://phabricator.kde.org/D27459

AFFECTED FILES
  src/ktoolbarhandler.cpp

To: mlaurent, dfaure, apol
Cc: aacid, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, 
bruns

Re: 2 kirigami fixes for a point release

[David Edmundson]

> > IMHO distributions using Plasma LTS, Plasma team & other stakeholders should
> > team up here and maintain a matching LTS branch of Frameworks together at 
> > the
> > central KDE repos together. Well, and a version also satisfying other 
> > clients
> > of KF, like non-workspace applications from KDE.
> >

Just to  clarify something. "the Plasma team" is not unified in the
position that there should be any changes to the current framework's
release cycle.

> So perhaps we could say that the KF version which
happens to be the dependency for a Plasma LTS release could have bugfix
releases?

Note that next Plasma LTS is a different case anyway as KF6 will be
well into development and KF5 branches will be somewhat frozen. The
exact details of which is another discussion.

David

D27463: KconfigXT: Add a value attribute to Enum field choices

[Nathaniel Graham]

ngraham added inline comments.

INLINE COMMENTS

> CTestCostData.txt:1
> +---

Seems like this file was added in error

> LastTest.log:3
> +--
> +End testing: Jan 29 14:08 CET

Seems like this file was added in error

REPOSITORY
  R237 KConfig

REVISION DETAIL
  https://phabricator.kde.org/D27463

To: meven, ervin, bport, crossi, #frameworks
Cc: ngraham, davidre, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, 
bruns

D26769: Always strip html if server does not support it

[Nathaniel Graham]

ngraham added a comment.


  +1 yes please

REPOSITORY
  R289 KNotifications

BRANCH
  stripcorrently

REVISION DETAIL
  https://phabricator.kde.org/D26769

To: nicolasfella, #frameworks, broulik, mart
Cc: ngraham, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, bruns

D27444: Added top area

[Nathaniel Graham]

ngraham added a comment.


  Oops, you're right! My mistake, sorry.
  
  Will resume the review.

REPOSITORY
  R242 Plasma Framework (Library)

REVISION DETAIL
  https://phabricator.kde.org/D27444

To: niccolove, #vdg, ngraham, ndavis
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D27334: Fix pri file: have qmake name of QtGui as dep, do not fail with CamelCase includes

[Nathaniel Graham]

ngraham added reviewers: vkrause, apol.

REPOSITORY
  R280 Prison

REVISION DETAIL
  https://phabricator.kde.org/D27334

To: kossebau, svuorela, vkrause, apol
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D27083: [PC2]Give Label integer width.

[George Vogiatzis]

gvgeo added a comment.


  Should I close this patch then?
  The only place I've seen this problem is in tests.
  I don't know if there is any place that is affected.

REPOSITORY
  R242 Plasma Framework (Library)

REVISION DETAIL
  https://phabricator.kde.org/D27083

To: gvgeo, #plasma, #vdg, ndavis, davidedmundson
Cc: davidedmundson, kde-frameworks-devel, Orage, LeGast00n, The-Feren-OS-Dev, 
cblack, jraleigh, zachus, fbampaloukas, GB_2, ragreen, michaelh, ZrenBot, 
ngraham, bruns, alexeymin, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, ahiemstra, mart

D27083: [PC2]Give Label integer width.

[George Vogiatzis]

gvgeo added a comment.


  I see, so paintedHeight is not exactly perfect above.
  
  > But I don't really understand how this helps anything in a reliable way.
  >  Layouts will override widths after a layout invalidation. Correctly set 
anchors would override it.
  
  RowLayout, FlowLayout and GridLayout will indeed correct label to integer.
  
  But Row, Flow and Grid do not affect the width, and place the next item with 
fractional x position. The problem exist in more tests, but is easier to see in 
checkboxes.
  
  > Also, why is only PC2 affected?
  
  QtQuick 2 gives label integer size. While QtQuick 1 does not.

REPOSITORY
  R242 Plasma Framework (Library)

REVISION DETAIL
  https://phabricator.kde.org/D27083

To: gvgeo, #plasma, #vdg, ndavis, davidedmundson
Cc: davidedmundson, kde-frameworks-devel, Orage, LeGast00n, The-Feren-OS-Dev, 
cblack, jraleigh, zachus, fbampaloukas, GB_2, ragreen, michaelh, ZrenBot, 
ngraham, bruns, alexeymin, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, ahiemstra, mart

D27475: Make kwapper/kshell spawn klauncher5 if needed

[Aleix Pol Gonzalez]

apol accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R303 KInit

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D27475

To: davidedmundson, apol
Cc: apol, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, 
bruns

D27083: [PC2]Give Label integer width.

[David Edmundson]

davidedmundson added a comment.


  From a logical viewpoirnt it doesn't make sense. It's a binding loop. 
Changing the width will re-lay out, which will change the paintedWidth, which 
will change the width.
  Practically QQuickTextItem has a catch against that (see qquicktext.cpp: 
internalWidthUpdate)  and it will stop after the first pass without a warning.
  
  But I don't really understand how this helps anything in a reliable way.
  Layouts will override widths after a layout invalidation. Correctly set 
anchors would override it.
  It's almost always wrong for a component to set it's own size (as opposed to 
it's implict size) as the consumer of the API will inevitably change it
  
  Also, why is only PC2 affected?

REPOSITORY
  R242 Plasma Framework (Library)

REVISION DETAIL
  https://phabricator.kde.org/D27083

To: gvgeo, #plasma, #vdg, ndavis, davidedmundson
Cc: davidedmundson, kde-frameworks-devel, Orage, LeGast00n, The-Feren-OS-Dev, 
cblack, jraleigh, zachus, fbampaloukas, GB_2, ragreen, michaelh, ZrenBot, 
ngraham, bruns, alexeymin, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, ahiemstra, mart

D27460: fix layout size hints for button labels

[David Edmundson]

davidedmundson added inline comments.

INLINE COMMENTS

> mart wrote in button3.qml:90
> added

You didn't even run this :(

1. icon.name not icon.source
2. now the comment next to it is wrong
3. there's a binding loop

4. if I make a test without any text, which is what the thing you're supposedly 
fixing was doing, I don't get an icon

REPOSITORY
  R242 Plasma Framework (Library)

REVISION DETAIL
  https://phabricator.kde.org/D27460

To: mart, #plasma, davidedmundson
Cc: davidedmundson, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, 
ngraham, bruns

D24004: Teach kwaylandscanner about PrimarySelection

[David Edmundson]

davidedmundson accepted this revision.
davidedmundson added a comment.
This revision is now accepted and ready to land.


  I'm skeptical that kwaylandscanner adds anything, especially when we want to 
pretty much clone a class, but sure.
  
  In terms of the names.
  
  As for V1. We're not entirely consistent.
  
  For anything unstable with the z prefix, it's probably worth it.
  Otherwise we're trying to write a stable interface round something that 
inherently isn't stable...which is asking for trouble.

REPOSITORY
  R127 KWayland

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D24004

To: gladhorn, #kwin, davidedmundson
Cc: meven, davidedmundson, romangg, zzag, kde-frameworks-devel, LeGast00n, 
cblack, GB_2, michaelh, ngraham, bruns

D24004: Teach kwaylandscanner about PrimarySelection

[Méven Car]

meven added a comment.


  ping reviewers :)

REPOSITORY
  R127 KWayland

REVISION DETAIL
  https://phabricator.kde.org/D24004

To: gladhorn, #kwin
Cc: meven, davidedmundson, romangg, zzag, kde-frameworks-devel, LeGast00n, 
cblack, GB_2, michaelh, ngraham, bruns

D27083: [PC2]Give Label integer width.

[George Vogiatzis]

gvgeo added a comment.


  @davidedmundson ping

REPOSITORY
  R242 Plasma Framework (Library)

REVISION DETAIL
  https://phabricator.kde.org/D27083

To: gvgeo, #plasma, #vdg, ndavis, davidedmundson
Cc: davidedmundson, kde-frameworks-devel, Orage, LeGast00n, The-Feren-OS-Dev, 
cblack, jraleigh, zachus, fbampaloukas, GB_2, ragreen, michaelh, ZrenBot, 
ngraham, bruns, alexeymin, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, ahiemstra, mart

D27460: fix layout size hints for button labels

[Marco Martin]

mart updated this revision to Diff 75927.
mart added a comment.


  - add an icon

REPOSITORY
  R242 Plasma Framework (Library)

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27460?vs=75922=75927

BRANCH
  phab/buttonslayout

REVISION DETAIL
  https://phabricator.kde.org/D27460

AFFECTED FILES
  src/declarativeimports/plasmacomponents3/Button.qml
  src/declarativeimports/plasmacomponents3/TabButton.qml
  src/declarativeimports/plasmacomponents3/TextField.qml
  src/declarativeimports/plasmacomponents3/ToolButton.qml
  tests/components/button3.qml

To: mart, #plasma, davidedmundson
Cc: davidedmundson, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, 
ngraham, bruns

D27460: fix layout size hints for button labels

[Marco Martin]

mart marked an inline comment as done.
mart added inline comments.

INLINE COMMENTS

> davidedmundson wrote in button3.qml:90
> this doesn't contain an icon, which is the majority of what this patch is 
> about

added

REPOSITORY
  R242 Plasma Framework (Library)

REVISION DETAIL
  https://phabricator.kde.org/D27460

To: mart, #plasma, davidedmundson
Cc: davidedmundson, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, 
ngraham, bruns

D27460: fix layout size hints for button labels

[David Edmundson]

davidedmundson added inline comments.

INLINE COMMENTS

> button3.qml:90
>  text: "AA"
> -// implicitWidth: minimumWidth FIXME, there is no equivalent?
> +implicitWidth: Layout.minimumWidth
>  }

this doesn't contain an icon, which is the majority of what this patch is about

REPOSITORY
  R242 Plasma Framework (Library)

REVISION DETAIL
  https://phabricator.kde.org/D27460

To: mart, #plasma, davidedmundson
Cc: davidedmundson, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, 
ngraham, bruns

D27475: Make kwapper/kshell spawn klauncher5 if needed

[David Edmundson]

davidedmundson updated this revision to Diff 75924.
davidedmundson added a comment.


  update

REPOSITORY
  R303 KInit

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27475?vs=75914=75924

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D27475

AFFECTED FILES
  CMakeLists.txt
  src/kdeinit/CMakeLists.txt
  src/kshell/CMakeLists.txt
  src/kwrapper/CMakeLists.txt
  src/wrapper.cpp

To: davidedmundson
Cc: apol, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, 
bruns

D27476: [KDBusConnectionPool] Handle the case of no qApp

[Aleix Pol Gonzalez]

apol added inline comments.

INLINE COMMENTS

> kdbusconnectionpool.cpp:66
> +if (!QCoreApplication::instance()) {
> +return QDBusConnection::sessionBus();
> +}

It feels like we should be using the s_perThreadConnection when we're not on a  
QApplication. Non-QApplications might still have threads.

REPOSITORY
  R271 KDBusAddons

REVISION DETAIL
  https://phabricator.kde.org/D27476

To: davidedmundson
Cc: apol, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, 
bruns

D27475: Make kwapper/kshell spawn klauncher5 if needed

[Aleix Pol Gonzalez]

apol added inline comments.

INLINE COMMENTS

> CMakeLists.txt:57
>  find_package(KF5Config ${KF5_DEP_VERSION} REQUIRED)
> +find_package(KF5DBusAddons ${KF5_DEP_VERSION} REQUIRED)
>  find_package(KF5DocTools ${KF5_DEP_VERSION})

I suppose this should be if (NOT WIN32)?

I'm not entirely sure why it's just added to some.

REPOSITORY
  R303 KInit

REVISION DETAIL
  https://phabricator.kde.org/D27475

To: davidedmundson
Cc: apol, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, 
bruns

D27460: fix layout size hints for button labels

[Marco Martin]

mart added a comment.


  latest version, plasmacontrols 2 and 3 one beside the other
  F8110874: Screenshot_20200218_160904.png 


REPOSITORY
  R242 Plasma Framework (Library)

REVISION DETAIL
  https://phabricator.kde.org/D27460

To: mart, #plasma, davidedmundson
Cc: davidedmundson, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, 
ngraham, bruns

D27460: fix layout size hints for button labels

[Marco Martin]

mart updated this revision to Diff 75922.
mart added a comment.


  - some quirks to make it more similar to pc2

REPOSITORY
  R242 Plasma Framework (Library)

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27460?vs=75833=75922

BRANCH
  phab/buttonslayout

REVISION DETAIL
  https://phabricator.kde.org/D27460

AFFECTED FILES
  src/declarativeimports/plasmacomponents3/Button.qml
  src/declarativeimports/plasmacomponents3/TabButton.qml
  src/declarativeimports/plasmacomponents3/TextField.qml
  src/declarativeimports/plasmacomponents3/ToolButton.qml
  tests/components/button3.qml

To: mart, #plasma, davidedmundson
Cc: davidedmundson, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, 
ngraham, bruns

D27478: Add a --replace option to kded5

[Aleix Pol Gonzalez]

apol created this revision.
apol added reviewers: Plasma, Frameworks.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
apol requested review of this revision.

REVISION SUMMARY
  Allows restarting kded5 properly, useful when trying new modules.

TEST PLAN
  restarted it

REPOSITORY
  R297 KDED

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D27478

AFFECTED FILES
  src/kded.cpp

To: apol, #plasma, #frameworks
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D27463: KconfigXT: Add a value attribute to Enum field choices

[Méven Car]

meven updated this revision to Diff 75917.
meven added a comment.


  Default value must refere to the choice name

REPOSITORY
  R237 KConfig

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27463?vs=75852=75917

BRANCH
  arcpatch-D27463

REVISION DETAIL
  https://phabricator.kde.org/D27463

AFFECTED FILES
  Testing/Temporary/CTestCostData.txt
  Testing/Temporary/LastTest.log
  autotests/kconfig_compiler/test4.cpp.ref
  autotests/kconfig_compiler/test4.kcfg
  src/core/kcoreconfigskeleton.cpp
  src/core/kcoreconfigskeleton.h
  src/kconfig_compiler/KConfigCommonStructs.h
  src/kconfig_compiler/KConfigSourceGenerator.cpp
  src/kconfig_compiler/KConfigXmlParser.cpp
  src/kconfig_compiler/kcfg.xsd

To: meven, ervin, bport, crossi, #frameworks
Cc: davidre, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, 
bruns

D27463: KconfigXT: Add a value attribute to Enum field choices

[Méven Car]

meven added a dependent revision: D27477: KCM/Kwinoptions: Port title bar and 
window actions tabs UI and conf to KConfigXT.

REPOSITORY
  R237 KConfig

REVISION DETAIL
  https://phabricator.kde.org/D27463

To: meven, ervin, bport, crossi, #frameworks
Cc: davidre, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, 
bruns

D27475: Make kwapper/kshell spawn klauncher5 if needed

[David Edmundson]

davidedmundson added a comment.


  Requires D27476  to not crash

REPOSITORY
  R303 KInit

REVISION DETAIL
  https://phabricator.kde.org/D27475

To: davidedmundson
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D27476: [KDBusConnectionPool] Handle the case of no qApp

[David Edmundson]

davidedmundson created this revision.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
davidedmundson requested review of this revision.

REVISION SUMMARY
  If we don't have a QApplication we can't use the thread-local
  QDBusConnection, but we can at least return something valid.
  
  Intended use case is to call KDEInitInterface::ensureKdeinitRunning can
  be called from a process with no QApplication.

TEST PLAN
  Used in a process with no QApplication

REPOSITORY
  R271 KDBusAddons

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D27476

AFFECTED FILES
  src/kdbusconnectionpool.cpp

To: davidedmundson
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D27475: Make kwapper/kshell spawn klauncher5 if needed

[David Edmundson]

davidedmundson created this revision.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
davidedmundson requested review of this revision.

REVISION SUMMARY
  In an attempt to phase kinit out plasma will at some point stop spawning 
klauncher5
  
  This means we need the cli-tools to spawn it themselves if activated for
  full compatibility

TEST PLAN
  didn't spawn kdeinit5
  ran kwrapper5 ls

REPOSITORY
  R303 KInit

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D27475

AFFECTED FILES
  CMakeLists.txt
  src/kdeinit/CMakeLists.txt
  src/kshell/CMakeLists.txt
  src/kwrapper/CMakeLists.txt
  src/wrapper.cpp

To: davidedmundson
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D27459: Port QLinkedList which is deprecated in qt5.15

[David Faure]

dfaure added a comment.


  This code only seems to do append() and contains(), a QVector (contiguous 
area of memory) is better than a std::list (individual nodes spread all over 
the memory, more cache lines to load)

REPOSITORY
  R263 KXmlGui

BRANCH
  port_QLinkedList (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D27459

To: mlaurent, dfaure, apol
Cc: aacid, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, 
bruns

Re: Standardizing Qt logging categories used in KF

[Aleix Pol]

On Mon, Feb 17, 2020 at 7:43 PM Friedrich W. H. Kossebau
 wrote:
>
> Hi,
>
> while going through the KF modules to adapt to the new
> ecm_qt_install_logging_categories() macro* to auto-generate KDebugSettings
> .categories (& .renamecategories) files I once more found there is no real
> naming pattern for the logging categories.
> * https://api.kde.org/ecm/module/ECMQtDeclareLoggingCategory.html
>
> Examples:
> org.kde.attica
> org.kde.pim.kcalcore
> kf5.kconfig.core
> kf5.kconfigwidgets
> sonnet.core
> sonnet.plugins.aspell
> kf5.kemoticons.plugin_adium
>
> As a result one cannot "calculate" the name which would be used for a given
> library (or feature), but has to first look that up (or relying on
> kdebugsettings & maintained .categories file). Also am I missing the ability
> from KDebug times where there was the option to control debug output per
> certain feature across libraries/KF modules.
>
> My proposal would be to switch to use these patterns:
>
> "kf".[.][.]
> "kf"...[.]
> "kf"..[.]
> "kf"..[.]
>
> So the examples would become:
> kf.attica
> kf.calendarcore
> kf.config.core
> kf.configwidgets
> kf.sonnet.core
> kf.sonnet.clients.aspell
> kf.emoticons.adium
>
> If people agree on such standardization, I would propose to do that renaming
> already now and not only at KF6 time. Given the categories being rather
> undocumented, usually only looked up when needed and kdebugsettings also
> supporting renames, I would think we can improve the situation already now.
> Having clear and known categories also might help once reaching work on KF6,
> when logged debugging might be more used during the Qt6 porting and other 5->6
> work.
>
>
> Please head over to
> https://phabricator.kde.org/T12716
> for a detailed description and reasoning of the current proposal to the
> problem, and join the discussion over there, so we have a central place to
> collect and track comments/ideas/work.
>
> Cheers
> Friedrich

Standardising the names make sense. I'm not sure if we need a
compatibility path for old names though, people/distrosmust have
configured some things.

Aleix

Re: New Framework Review: KDAV

[Sandro Knauß]

Hi,

> In mostly all files it is not clear if the LGPL or the GPL is meant (stating
> "GNU Library General Public License" and referring to the GPL text at the
> end of the statement). This license statement is used for all files except
> autotests/fakesever.cpp and autotests/fakeserver.h.
> Luckily, from the copyright statements there are only 3 copyright holders:
> Tobias, Sandro and Gregory. I put all 3 into CC.
> 
> @Tobias, Sandro, Gregory: Can you clarify that the code you are holding
> copyright about in this repository is licensed according to
> LGPL-2.0-or-later?

I'm fine with (re-)licensing this code to  LGPL-2.0-or-later.

Sandro



signature.asc
Description: This is a digitally signed message part.

Re: 2 kirigami fixes for a point release

[Nate Graham]

On 2020-02-16 14:43, Albert Astals Cid wrote:

Maybe i explain myself wrongly, i'm not blaming distros at all.

They made a decision, we/I may agree with them or not, that's *my/our* problem, 
what I was disagreeing is to us having to do extra work because someone elses 
(the distros) decision.


We already do this: it's called the Plasma LTS product. :-) It's been 
specifically created to cater to various distros' desires for an 
extended-support product they can ship to users of their own LTS releases.


But yes, I can also agree with more tests, better stability, moving to 
GitLab so tests are run before merging, etc. I think we can all agree 
with that.


However all the autotests in the world will not resolve the fundamental 
incompatibility between the Plasma LTS product, which is built around 
the release model of extended, ongoing bugfix releases, and Frameworks, 
which is built around a rolling release model with no bugfix releases at 
all.


If we don't want to change the incompatible way that Frameworks plugs 
into an LTS Plasma release, and we think our opinions regarding how a 
distro ought to ship software are valid, then I think it's time for us 
to take the lead and produce a real reference distro that shows how *we* 
think KDE software should be presented to users. Basically, we 
acknowledge that Neon is already an actual OS--the "KDE OS"--and we 
treat is as such, explicitly advertising it as a fully supported OS 
suitable for users to install and vendors to ship hardware with (as in 
fact Slimbook already does!). See also https://phabricator.kde.org/T12707.


If we don't want to be so opinionated regarding how software should be 
released--perhaps out of fear of alienating sponsors that produce LTS 
distros, for example--then maybe it's time to swallow our opinions, 
respect the way that those distro partners currently ship software even 
if we disagree with it, and adjust Frameworks to better support the 
needs of their LTS releases.



Nate

D27459: Port QLinkedList which is deprecated in qt5.15

[Aleix Pol Gonzalez]

apol added a comment.


  In D27459#613205 , @aacid wrote:
  
  > Are we sure we can lose the features of QLinkedList here?
  >
  > maybe makes more sense to use std::list that has the same features as 
QLinkedList?
  
  
  I thought so too, but we just iterate and append to it QVector should be fine 
there.
  Could be missing something...

REPOSITORY
  R263 KXmlGui

BRANCH
  port_QLinkedList (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D27459

To: mlaurent, dfaure, apol
Cc: aacid, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, 
bruns

D27460: fix layout size hints for button labels

[David Edmundson]

davidedmundson requested changes to this revision.
davidedmundson added a comment.
This revision now requires changes to proceed.


  Please update tests/components to have it failing before and now passing.

REPOSITORY
  R242 Plasma Framework (Library)

REVISION DETAIL
  https://phabricator.kde.org/D27460

To: mart, #plasma, davidedmundson
Cc: davidedmundson, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, 
ngraham, bruns

D27468: Don't double delete CommentsModel

[David Edmundson]

This revision was automatically updated to reflect the committed changes.
Closed by commit R304:5c7ee50bf900: Dont double delete CommentsModel 
(authored by davidedmundson).

REPOSITORY
  R304 KNewStuff

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27468?vs=75866=75886

REVISION DETAIL
  https://phabricator.kde.org/D27468

AFFECTED FILES
  src/qtquick/quickitemsmodel.cpp

To: davidedmundson, leinir
Cc: leinir, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, 
bruns

D27468: Don't double delete CommentsModel

[Dan Leinir Turthra Jensen]

leinir accepted this revision.
leinir added a comment.
This revision is now accepted and ready to land.


  Quite right. Looks like some leftovers from before that caching was added, 
shippit :)

REPOSITORY
  R304 KNewStuff

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D27468

To: davidedmundson, leinir
Cc: leinir, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, 
bruns

D27463: KconfigXT: Add a value attribute to Enum field choices

[Méven Car]

meven added a comment.


  In D27463#613114 , @davidre wrote:
  
  > If you touch the xsd do you neeed to increase the version number?
  
  
  That would be a good practice but how to publish a 1.1 version ?
  And what is the point ? I mean this xsd and associated dtd is AFAIK not 
really used (kcfg files are not even validated against it, in kconfig_compiler).
  This xsd is mostly living documentation.
  
  It was not done previously the 
  https://phabricator.kde.org/D7415

REPOSITORY
  R237 KConfig

REVISION DETAIL
  https://phabricator.kde.org/D27463

To: meven, ervin, bport, crossi, #frameworks
Cc: davidre, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, 
bruns