[frameworks-kuserfeedback] [Bug 426470] KMail User feedback shows strange values for display setup

[Volker Krause]

https://bugs.kde.org/show_bug.cgi?id=426470

Volker Krause  changed:

   What|Removed |Added

 Status|REPORTED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Volker Krause  ---


*** This bug has been marked as a duplicate of bug 425549 ***

-- 
You are receiving this mail because:
You are watching all bug changes.

[ksmserver] [Bug 425982] Session restore broken with KDE_APPLICATIONS_AS_SCOPE

[Volker Krause]

https://bugs.kde.org/show_bug.cgi?id=425982

Volker Krause  changed:

   What|Removed |Added

 CC||ahartm...@gmail.com

-- 
You are receiving this mail because:
You are watching all bug changes.

[ksmserver] [Bug 425982] Session restore broken with KDE_APPLICATIONS_AS_SCOPE

[Volker Krause]

https://bugs.kde.org/show_bug.cgi?id=425982

--- Comment #5 from Volker Krause  ---
Both Andreas' and my observation were hinting at session saving breaking rather
than session restore though. Things still in the session config are correctly
restored here it seems.

The log during shutdown seemed to indicate X going away before processes had a
chance to be cleanly terminated, both for applications (losing stuff they save
themselves on exit, like kwrite's recent documents), and for kwin (which iiuc
stores the list of applications to restore).

-- 
You are receiving this mail because:
You are watching all bug changes.

[Akonadi] [Bug 378436] Instance create job emits result too early

[Volker Krause]

https://bugs.kde.org/show_bug.cgi?id=378436

Volker Krause  changed:

   What|Removed |Added

 Blocks|416403  |


Referenced Bugs:

https://bugs.kde.org/show_bug.cgi?id=416403
[Bug 416403] During account wizard using @protonmail.com, get "Kmail could not
convert value of setting 'Authentication' to required type"
-- 
You are receiving this mail because:
You are watching all bug changes.

[Akonadi] [Bug 378436] Instance create job emits result too early

[Volker Krause]

https://bugs.kde.org/show_bug.cgi?id=378436

Volker Krause  changed:

   What|Removed |Added

 Blocks|416403  |


Referenced Bugs:

https://bugs.kde.org/show_bug.cgi?id=416403
[Bug 416403] During account wizard using @protonmail.com, get "Kmail could not
convert value of setting 'Authentication' to required type"
-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmail2] [Bug 416403] During account wizard using @protonmail.com, get "Kmail could not convert value of setting 'Authentication' to required type"

[Volker Krause]

https://bugs.kde.org/show_bug.cgi?id=416403

Volker Krause  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|CONFIRMED   |RESOLVED

--- Comment #26 from Volker Krause  ---
This has been fixed in 20.04.0 by
https://commits.kde.org/kmail-account-wizard/4b65460dc48b0ebe6ec3bd3f9615d462793bdba6

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmail2] [Bug 416403] During account wizard using @protonmail.com, get "Kmail could not convert value of setting 'Authentication' to required type"

[Volker Krause]

https://bugs.kde.org/show_bug.cgi?id=416403

Volker Krause  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|CONFIRMED   |RESOLVED

--- Comment #26 from Volker Krause  ---
This has been fixed in 20.04.0 by
https://commits.kde.org/kmail-account-wizard/4b65460dc48b0ebe6ec3bd3f9615d462793bdba6

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmail2] [Bug 416403] During account wizard using @protonmail.com, get "Kmail could not convert value of setting 'Authentication' to required type"

[Volker Krause]

https://bugs.kde.org/show_bug.cgi?id=416403

Volker Krause  changed:

   What|Removed |Added

 CC||vkra...@kde.org
 Depends on|378436  |


Referenced Bugs:

https://bugs.kde.org/show_bug.cgi?id=378436
[Bug 378436] Instance create job emits result too early
-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmail2] [Bug 416403] During account wizard using @protonmail.com, get "Kmail could not convert value of setting 'Authentication' to required type"

[Volker Krause]

https://bugs.kde.org/show_bug.cgi?id=416403

Volker Krause  changed:

   What|Removed |Added

 CC||vkra...@kde.org
 Depends on|378436  |


Referenced Bugs:

https://bugs.kde.org/show_bug.cgi?id=378436
[Bug 378436] Instance create job emits result too early
-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kuserfeedback] [Bug 425549] Kate "User Feedback" reports incorrect screen details

[Volker Krause]

https://bugs.kde.org/show_bug.cgi?id=425549

Volker Krause  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
  Latest Commit||https://invent.kde.org/libr
   ||aries/kuserfeedback/commit/
   ||b0cdb302bd569b446bba96f323d
   ||046b0b3d14cd3

--- Comment #4 from Volker Krause  ---
Git commit b0cdb302bd569b446bba96f323d046b0b3d14cd3 by Volker Krause.
Committed on 22/08/2020 at 09:12.
Pushed by vkrause into branch 'master'.

Also record the device pixel ratio

That cannot be determined from the (scaled) values we record so far for
the screens.

M  +6-1src/console/schematemplates/screens.schema
M  +1-0src/provider/core/screeninfosource.cpp

https://invent.kde.org/libraries/kuserfeedback/commit/b0cdb302bd569b446bba96f323d046b0b3d14cd3

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kuserfeedback] [Bug 425050] I see you're already losing users' trust over this... Here are some suggestions.

[Volker Krause]

https://bugs.kde.org/show_bug.cgi?id=425050

Volker Krause  changed:

   What|Removed |Added

 Resolution|--- |NOT A BUG
 Status|REPORTED|RESOLVED

--- Comment #3 from Volker Krause  ---
(5) see #420955, this would retain the majority of the telemetry code, at best
the submission code could be broken out. So this will bring little gain at a
huge extra complexity. IMHO the  more viable approach in case of such
fundamental concerns is rather to convince a distro to not include
KUserFeedback in applications where it's build-time optional, and patch it out
from applications where it's not.
(7) That could make it more discoverable indeed, let's put that into a separate
specific ticket though, so it's not getting lost between the various other
points in here.
(8) As you said yourself, this is likely going to be way too bothersome to use.
If you just have the slightest concerns about participating in that, just don't
and disable it. Even the existing sharing controls actually turned out to be
overkill, in practice the vast majority of people have this either set to all
or nothing, the gain of adding even more fine-grained controls therefore
doesn't seem to be worth the effort.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kuserfeedback] [Bug 425050] I see you're already losing users' trust over this... Here are some suggestions.

[Volker Krause]

https://bugs.kde.org/show_bug.cgi?id=425050

Volker Krause  changed:

   What|Removed |Added

 Status|REPORTED|RESOLVED
 Resolution|--- |NOT A BUG

--- Comment #1 from Volker Krause  ---
I can only comment on this as far as the KUserFeedback framework is concerned
(which is what this ticket is reported for), not packaging, use  or integration
in individual applications, or stuff that happens on some forum somewhere.
(1) that's an issue of either a specific application using the framework or its
packaging, nothing the framework can influence.
(2) seems to refer to #418981
(3) claims something happened on Reddit -> not a framework issue
(4) we don't
(5) see #420955
(6) there are internal names, changing them will not change anything apart from
causing effort better spent elsewhere
(7) that exists, there is the "audit log" feature in the framework, see
~/.local/share///kuserfeedback/audit/*.log. The reference
config dialog of the framework also offers UI access to that if data has
already been submitted ("View previously submitted data..." link below the list
of submitted data).
(8) the reference config dialog of the framework offers raw data preview,
although a bit hidden (the small icon in the bottom right corner of the list
with the human-readable transmitted information)

So all of this is either already covered, for different components, or a
duplicate of other reports.

-- 
You are receiving this mail because:
You are watching all bug changes.

[KDE Itinerary] [Bug 424853] Build fails with zxing-cpp 1.1.0

[Volker Krause]

https://bugs.kde.org/show_bug.cgi?id=424853

Volker Krause  changed:

   What|Removed |Added

 Resolution|--- |FIXED
  Latest Commit||https://invent.kde.org/pim/
   ||kitinerary/commit/8bf24e237
   ||2b142f1a2189ad951fa396c5a4e
   ||0e74
 Status|REPORTED|RESOLVED

--- Comment #1 from Volker Krause  ---
Git commit 8bf24e2372b142f1a2189ad951fa396c5a4e0e74 by Volker Krause.
Committed on 01/08/2020 at 07:25.
Pushed by vkrause into branch 'release/20.08'.

Fix build with zxing 1.1.0

M  +1-0src/CMakeLists.txt

https://invent.kde.org/pim/kitinerary/commit/8bf24e2372b142f1a2189ad951fa396c5a4e0e74

-- 
You are receiving this mail because:
You are watching all bug changes.

Re: Dropping the moderation by default flag

[Volker Krause]

On Tuesday, 21 July 2020 21:16:00 CEST Albert Astals Cid wrote:
> Hi, this list has an unusual setting [for kde mailing lists] inherited from
> kde-core-devel that is that even subscribed people get moderated, and then
> the list moderator can decide to clear the moderate flag for each person
> one by one.
> 
> I'm proposing to change that because:
>  * it's non consistent with the rest of kde mailing lists
>  * as moderator of this list i don't think i've seen ever any spam coming
> from a subscribed member.
> 
> Opinions?

+1. That setup on core-devel was already around in the early 2000s, so 
probably a response to some events from 20 years ago, I doubt we still need 
that today.

Regards,
Volker

[neon] [Bug 424339] itinerary is missing QML dependencies

[Volker Krause]

https://bugs.kde.org/show_bug.cgi?id=424339

--- Comment #6 from Volker Krause  ---
Git commit 9690d4c1a8cb376c3db02ab4548f0f6eb47e31e5 by Volker Krause.
Committed on 20/07/2020 at 14:55.
Pushed by vkrause into branch 'master'.

Mark org.kde.kosmindoormap as QML runtime dependency

M  +1-0CMakeLists.txt

https://invent.kde.org/pim/itinerary/commit/9690d4c1a8cb376c3db02ab4548f0f6eb47e31e5

-- 
You are receiving this mail because:
You are watching all bug changes.

[neon] [Bug 424339] itinerary is missing QML dependencies

[Volker Krause]

https://bugs.kde.org/show_bug.cgi?id=424339

--- Comment #4 from Volker Krause  ---
Git commit df5acf06b266321d90ef5116a4b278305117e655 by Volker Krause.
Committed on 18/07/2020 at 08:35.
Pushed by vkrause into branch 'master'.

Fix build with older CMake versions

M  +9-5src/map-quick/CMakeLists.txt

https://invent.kde.org/libraries/kpublictransport/commit/df5acf06b266321d90ef5116a4b278305117e655

-- 
You are receiving this mail because:
You are watching all bug changes.

D29747: Deprecate AbstractBarcode::minimumSize() also for the compiler

[Volker Krause]

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

REPOSITORY
  R280 Prison

BRANCH
  fullydeprecateminimumsize

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

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

Re: Shift for parts of the CI system to Qt 5.15

[Volker Krause]

On Saturday, 20 June 2020 08:20:18 CEST Ben Cooksley wrote:
> Hi all,
> 
> This weekend parts of our CI system shifted to using Qt 5.15, with all
> FreeBSD builds now being based on Qt 5.15. We also shifted all Linux
> builds of Plasma, and the latest Qt version build of Frameworks to Qt
> 5.15 as well (apologies for the massive amount of email this kicked
> up)
> 
> It has however exposed a series of SIC changes in Qt which will need
> to be adapted to. The list of affected projects appears to be as
> follows:
> - kalarm
> - kdesdk-kioslaves
> - kompare
> - subtitlecomposer

all fixed

> - kaffeine

This doesn't look like something caused by Qt 5.15, more like an issue with 
the FreeBSD DVB headers, builds on Linux.

> In addition, the following projects appear to have long standing build
> issues. It would be appreciated if they could please investigate and
> correct these:
> - kbibtex

fixed

> - atcore
> - kmymoney

MSVC-only, or rather GCC/clang being a bit too forgiving. 

atcore looks like an ambiguous default argument, removing that should fix it, 
but since this is a public interface I didn't want to just change this, being 
unable to estimate the impact.

kmymoney is using an exported class in two DLLs with the same export macro, 
that doesn't work. Needs more insights into the project to restructure that 
accordingly I think.

> - ring-kde

build errors seem to be in stuff downloaded by cmake!?

> Further, the following project appears to have a broken build due to
> SIC changes within another KDE project:
> - zanshin

fixed

Regards,
Volker

Re: Shift for parts of the CI system to Qt 5.15

[Volker Krause]

On Saturday, 20 June 2020 08:20:18 CEST Ben Cooksley wrote:
> Hi all,
> 
> This weekend parts of our CI system shifted to using Qt 5.15, with all
> FreeBSD builds now being based on Qt 5.15. We also shifted all Linux
> builds of Plasma, and the latest Qt version build of Frameworks to Qt
> 5.15 as well (apologies for the massive amount of email this kicked
> up)
> 
> It has however exposed a series of SIC changes in Qt which will need
> to be adapted to. The list of affected projects appears to be as
> follows:
> - kalarm
> - kdesdk-kioslaves
> - kompare
> - subtitlecomposer

all fixed

> - kaffeine

This doesn't look like something caused by Qt 5.15, more like an issue with 
the FreeBSD DVB headers, builds on Linux.

> In addition, the following projects appear to have long standing build
> issues. It would be appreciated if they could please investigate and
> correct these:
> - kbibtex

fixed

> - atcore
> - kmymoney

MSVC-only, or rather GCC/clang being a bit too forgiving. 

atcore looks like an ambiguous default argument, removing that should fix it, 
but since this is a public interface I didn't want to just change this, being 
unable to estimate the impact.

kmymoney is using an exported class in two DLLs with the same export macro, 
that doesn't work. Needs more insights into the project to restructure that 
accordingly I think.

> - ring-kde

build errors seem to be in stuff downloaded by cmake!?

> Further, the following project appears to have a broken build due to
> SIC changes within another KDE project:
> - zanshin

fixed

Regards,
Volker

Re: Shift for parts of the CI system to Qt 5.15

[Volker Krause]

On Saturday, 20 June 2020 08:20:18 CEST Ben Cooksley wrote:
> Hi all,
> 
> This weekend parts of our CI system shifted to using Qt 5.15, with all
> FreeBSD builds now being based on Qt 5.15. We also shifted all Linux
> builds of Plasma, and the latest Qt version build of Frameworks to Qt
> 5.15 as well (apologies for the massive amount of email this kicked
> up)
> 
> It has however exposed a series of SIC changes in Qt which will need
> to be adapted to. The list of affected projects appears to be as
> follows:
> - kalarm
> - kdesdk-kioslaves
> - kompare
> - subtitlecomposer

all fixed

> - kaffeine

This doesn't look like something caused by Qt 5.15, more like an issue with 
the FreeBSD DVB headers, builds on Linux.

> In addition, the following projects appear to have long standing build
> issues. It would be appreciated if they could please investigate and
> correct these:
> - kbibtex

fixed

> - atcore
> - kmymoney

MSVC-only, or rather GCC/clang being a bit too forgiving. 

atcore looks like an ambiguous default argument, removing that should fix it, 
but since this is a public interface I didn't want to just change this, being 
unable to estimate the impact.

kmymoney is using an exported class in two DLLs with the same export macro, 
that doesn't work. Needs more insights into the project to restructure that 
accordingly I think.

> - ring-kde

build errors seem to be in stuff downloaded by cmake!?

> Further, the following project appears to have a broken build due to
> SIC changes within another KDE project:
> - zanshin

fixed

Regards,
Volker

Re: New Framework Review: KDAV

[Volker Krause]

This has all been executed now, including the move on Gitlab and the necessary 
changes to the dependency metadata. So unless I'm missing something this 
should be all done now and we'll have KDAV in KF 5.72 as a drop-in replacement 
for the one released with 20.04 :)

Thanks everyone for helping with this!
Volker

On Sunday, 14 June 2020 11:53:42 CEST Albert Astals Cid wrote:
> El diumenge, 14 de juny de 2020, a les 10:17:01 CEST, Ben Cooksley va 
escriure:
> > On Sun, Jun 14, 2020 at 8:03 PM Volker Krause  wrote:
> > > With both 20.04.2 and 5.71.0 out I think it's now time to do this move.
> > > 
> > > What extra steps do we need to take now that the framework/application
> > > distinction exists in Gitlab as well? I guess this is the first case of
> > > a
> > > post-migration move. Also, what is the impact on the 20.04.3 release
> > > when we move this in Gitlab?
> > 
> > You'll need to file a Sysadmin ticket requesting we relocate the
> > repository from it's current home in pim/ to frameworks/
> > Gitlab will provide a redirect for this automatically, so existing
> > urls and clones won't be affected by this - although they will be
> > given a notice that it has moved.
> > 
> > Systems such as scripty won't be impacted by this as they use the
> > stable repository identifier.
> > 
> > In terms of the Release Service 20.04.3 release, Albert/Christoph will
> > need to comment on this.
> 
> It shouldn't, the release service scripts don't care about the subdir repos
> are in, and given gitlab follows moves, we shouldn't not have a problem
> either with things like pushing tags, etc.
> 
> Cheers,
>   Albert
> 
> > > Thanks,
> > > Volker
> > 
> > Cheers,
> > Ben
> > 
> > > On Sunday, 24 May 2020 08:52:17 CEST Volker Krause wrote:
> > > > The remaining issues that didn't change ABI anymore (movable value
> > > > types,
> > > > hide private methods/slots inside the private classes, etc) have long
> > > > since
> > > > been addressed.
> > > > 
> > > > I think there's two possible time slots to actually execute the move
> > > > to
> > > > frameworks now:
> > > > * ASAP, for the June release.
> > > > * For the July release, just in time for the 20.08 dependency freeze.
> > > > 
> > > > Opinions?
> > > > 
> > > > Thanks,
> > > > Volker
> > > > 
> > > > On Saturday, 4 April 2020 17:32:19 CEST Volker Krause wrote:
> > > > > Thanks for the review! We are cutting it close again with the 20.04
> > > > > deadline, but fortunately most of these findings aren't ABI-breaking
> > > > > :)
> > > > > 
> > > > > The result was discussed in more detail at the (virtual) PIM sprint,
> > > > > summary below for the record.
> > > > > 
> > > > > On Saturday, 4 April 2020 16:20:21 CEST Kevin Ottens wrote:
> > > > > > Hello,
> > > > > > 
> > > > > > On Saturday, 9 November 2019 12:33:54 CEST Volker Krause wrote:
> > > > > > > during Akademy there was a request to promote KDAV from KDE PIM
> > > > > > > to
> > > > > > > Frameworks for use by Plasma Mobile. KDAV is a framework that
> > > > > > > implements
> > > > > > > the CalDav/ CardDav/GroupDav protocol on top of KIO's WebDav
> > > > > > > support.
> > > > > > > It
> > > > > > > would be classified as a functional tier 3 framework.
> > > > > > > 
> > > > > > > So far we have fixed a number of obvious ABI-compatibility
> > > > > > > issues,
> > > > > > > removed
> > > > > > > QtXml[Patterns] usage from the public interface and relicensed
> > > > > > > GPL
> > > > > > > parts
> > > > > > > (apart from a bit of test code) to LGPL. The next step would be
> > > > > > > a more
> > > > > > > thorough review to identify changes necessary before becoming a
> > > > > > > Framework.
> > > > > > > 
> > > > > > > To avoid the last minute invasive changes we ended up doing for
> > > > > > > KCalendarCore, I'd propose the following timeline:
> > > > > > > 
> > > > > > > - identify and implement all ne

Re: New Framework Review: KDAV

[Volker Krause]

This has all been executed now, including the move on Gitlab and the necessary 
changes to the dependency metadata. So unless I'm missing something this 
should be all done now and we'll have KDAV in KF 5.72 as a drop-in replacement 
for the one released with 20.04 :)

Thanks everyone for helping with this!
Volker

On Sunday, 14 June 2020 11:53:42 CEST Albert Astals Cid wrote:
> El diumenge, 14 de juny de 2020, a les 10:17:01 CEST, Ben Cooksley va 
escriure:
> > On Sun, Jun 14, 2020 at 8:03 PM Volker Krause  wrote:
> > > With both 20.04.2 and 5.71.0 out I think it's now time to do this move.
> > > 
> > > What extra steps do we need to take now that the framework/application
> > > distinction exists in Gitlab as well? I guess this is the first case of
> > > a
> > > post-migration move. Also, what is the impact on the 20.04.3 release
> > > when we move this in Gitlab?
> > 
> > You'll need to file a Sysadmin ticket requesting we relocate the
> > repository from it's current home in pim/ to frameworks/
> > Gitlab will provide a redirect for this automatically, so existing
> > urls and clones won't be affected by this - although they will be
> > given a notice that it has moved.
> > 
> > Systems such as scripty won't be impacted by this as they use the
> > stable repository identifier.
> > 
> > In terms of the Release Service 20.04.3 release, Albert/Christoph will
> > need to comment on this.
> 
> It shouldn't, the release service scripts don't care about the subdir repos
> are in, and given gitlab follows moves, we shouldn't not have a problem
> either with things like pushing tags, etc.
> 
> Cheers,
>   Albert
> 
> > > Thanks,
> > > Volker
> > 
> > Cheers,
> > Ben
> > 
> > > On Sunday, 24 May 2020 08:52:17 CEST Volker Krause wrote:
> > > > The remaining issues that didn't change ABI anymore (movable value
> > > > types,
> > > > hide private methods/slots inside the private classes, etc) have long
> > > > since
> > > > been addressed.
> > > > 
> > > > I think there's two possible time slots to actually execute the move
> > > > to
> > > > frameworks now:
> > > > * ASAP, for the June release.
> > > > * For the July release, just in time for the 20.08 dependency freeze.
> > > > 
> > > > Opinions?
> > > > 
> > > > Thanks,
> > > > Volker
> > > > 
> > > > On Saturday, 4 April 2020 17:32:19 CEST Volker Krause wrote:
> > > > > Thanks for the review! We are cutting it close again with the 20.04
> > > > > deadline, but fortunately most of these findings aren't ABI-breaking
> > > > > :)
> > > > > 
> > > > > The result was discussed in more detail at the (virtual) PIM sprint,
> > > > > summary below for the record.
> > > > > 
> > > > > On Saturday, 4 April 2020 16:20:21 CEST Kevin Ottens wrote:
> > > > > > Hello,
> > > > > > 
> > > > > > On Saturday, 9 November 2019 12:33:54 CEST Volker Krause wrote:
> > > > > > > during Akademy there was a request to promote KDAV from KDE PIM
> > > > > > > to
> > > > > > > Frameworks for use by Plasma Mobile. KDAV is a framework that
> > > > > > > implements
> > > > > > > the CalDav/ CardDav/GroupDav protocol on top of KIO's WebDav
> > > > > > > support.
> > > > > > > It
> > > > > > > would be classified as a functional tier 3 framework.
> > > > > > > 
> > > > > > > So far we have fixed a number of obvious ABI-compatibility
> > > > > > > issues,
> > > > > > > removed
> > > > > > > QtXml[Patterns] usage from the public interface and relicensed
> > > > > > > GPL
> > > > > > > parts
> > > > > > > (apart from a bit of test code) to LGPL. The next step would be
> > > > > > > a more
> > > > > > > thorough review to identify changes necessary before becoming a
> > > > > > > Framework.
> > > > > > > 
> > > > > > > To avoid the last minute invasive changes we ended up doing for
> > > > > > > KCalendarCore, I'd propose the following timeline:
> > > > > > > 
> > > > > > > - identify and implement all ne

Re: New Framework Review: KDAV

[Volker Krause]

On Friday, 19 June 2020 01:16:20 CEST Friedrich W. H. Kossebau wrote:
> Am Samstag, 4. April 2020, 16:20:21 CEST schrieb Kevin Ottens:
> > Overall apidox would likely need a big pass of cleanups as well.
> 
> I locally prepared the addition of ECMAddQch usage for KDAV tonight, and
> while testing the output already did some small bits of minor cleanup
> (consistent casing of terms like URL, ETag, etc. in the texts), documenting
> CamelCase includes of classes as well triggering the documentation of
> namespace KDAV.

Thanks!

> One thing which should get fixed by someone with insights are all the
> remaining references to some "ResourceBase::retrieveItems()" in the docs
> (simply grep for the string to find those). That needs more context, or
> better some generalization what is meant there (seems something-Akonadi
> specific?).

I've added the full namespace now, but you are right, this leaks details about 
the origin of all this and should probably be abstracted/generalized.

Regards,
Volker

[KDE Itinerary] [Bug 404451] sncf confirmation email types to help development

[Volker Krause]

https://bugs.kde.org/show_bug.cgi?id=404451

--- Comment #36 from Volker Krause  ---
Git commit bc8b78d47829da0bec4facdff3bf1a740751e5ae by Volker Krause.
Committed on 17/06/2020 at 15:06.
Pushed by vkrause into branch 'release/20.04'.

Extract seat reservation information from Ouigo confirmations

M  +7-0src/extractors/sncf.js

https://invent.kde.org/pim/kitinerary/commit/bc8b78d47829da0bec4facdff3bf1a740751e5ae

-- 
You are receiving this mail because:
You are watching all bug changes.

Re: New Framework Review: KDAV

[Volker Krause]

With both 20.04.2 and 5.71.0 out I think it's now time to do this move.

What extra steps do we need to take now that the framework/application 
distinction exists in Gitlab as well? I guess this is the first case of a 
post-migration move. Also, what is the impact on the 20.04.3 release when we 
move this in Gitlab?

Thanks,
Volker

On Sunday, 24 May 2020 08:52:17 CEST Volker Krause wrote:
> The remaining issues that didn't change ABI anymore (movable value types,
> hide private methods/slots inside the private classes, etc) have long since
> been addressed.
> 
> I think there's two possible time slots to actually execute the move to
> frameworks now:
> * ASAP, for the June release.
> * For the July release, just in time for the 20.08 dependency freeze.
> 
> Opinions?
> 
> Thanks,
> Volker
> 
> On Saturday, 4 April 2020 17:32:19 CEST Volker Krause wrote:
> > Thanks for the review! We are cutting it close again with the 20.04
> > deadline, but fortunately most of these findings aren't ABI-breaking :)
> > 
> > The result was discussed in more detail at the (virtual) PIM sprint,
> > summary below for the record.
> > 
> > On Saturday, 4 April 2020 16:20:21 CEST Kevin Ottens wrote:
> > > Hello,
> > > 
> > > On Saturday, 9 November 2019 12:33:54 CEST Volker Krause wrote:
> > > > during Akademy there was a request to promote KDAV from KDE PIM to
> > > > Frameworks for use by Plasma Mobile. KDAV is a framework that
> > > > implements
> > > > the CalDav/ CardDav/GroupDav protocol on top of KIO's WebDav support.
> > > > It
> > > > would be classified as a functional tier 3 framework.
> > > > 
> > > > So far we have fixed a number of obvious ABI-compatibility issues,
> > > > removed
> > > > QtXml[Patterns] usage from the public interface and relicensed GPL
> > > > parts
> > > > (apart from a bit of test code) to LGPL. The next step would be a more
> > > > thorough review to identify changes necessary before becoming a
> > > > Framework.
> > > > 
> > > > To avoid the last minute invasive changes we ended up doing for
> > > > KCalendarCore, I'd propose the following timeline:
> > > > 
> > > > - identify and implement all necessary changes to the API and ABI
> > > > until
> > > > the
> > > > 20.04 Application release (that includes the still necessary move to
> > > > the
> > > > KF5 library namespace).
> > > 
> > > I'm likely late to the party, but here is what I found by looking at
> > > KDAV
> > > 
> > > master today (first day of the KDE PIM sprint):
> > >  * There's a few private methods or Q_SLOTS that I'd hide completely by
> > > 
> > > moving them to the d-pointer, for the slots we're using type safe
> > > connects
> > > so they don't even need to be marked as slots at all;
> > 
> > Cosmetic with no ABI impact, we can do that post 20.04 still.
> > 
> > >  * Is it worth making DavCollection moveable? It's only copyable right
> > >  now;
> > 
> > Probably yes, that's new API with no ABI break, so we can do that post
> > 20.04 as well.
> > 
> > >  * We might want to do something about "ctag" in DavCollection it's a
> > >  bit
> > > 
> > > obscure as a name (and the API doc doesn't help), also it seems to not
> > > be
> > > an official standard (while being widely supported) and there's the
> > > sync-token mechanism which has a RFC (RFC6578);
> > 
> > I have no idea what ctag is (I am only doing the technical work needed to
> > turn this into a framework, I didn't write this library).
> > 
> > >  * Why isn't DavCollectionModifyJob using DavCollection somehow? (might
> > >  just
> > > 
> > > be my ignorance but I find it surprising that it is solely based on a
> > > property mechanism);
> > 
> > I think this is to be able to control which properties get changed, rather
> > than sending the full set of them.
> > 
> > >  * DavCollections(Multi)FetchJob has a mysterious "protocol" parameter
> > >  on
> > > 
> > > its collectionDiscovered signal, is it really necessary? if it has to
> > > stay,
> > > shouldn't be at least documented? or at least a safer type than int?
> > 
> > Fixed in https://phabricator.kde.org/D28564 and
> > https://phabricator.kde.org/ D28566
> > 
> > > * DavCollectionsMultiFetchJob is inconsist

Re: New Framework Review: KDAV

[Volker Krause]

With both 20.04.2 and 5.71.0 out I think it's now time to do this move.

What extra steps do we need to take now that the framework/application 
distinction exists in Gitlab as well? I guess this is the first case of a 
post-migration move. Also, what is the impact on the 20.04.3 release when we 
move this in Gitlab?

Thanks,
Volker

On Sunday, 24 May 2020 08:52:17 CEST Volker Krause wrote:
> The remaining issues that didn't change ABI anymore (movable value types,
> hide private methods/slots inside the private classes, etc) have long since
> been addressed.
> 
> I think there's two possible time slots to actually execute the move to
> frameworks now:
> * ASAP, for the June release.
> * For the July release, just in time for the 20.08 dependency freeze.
> 
> Opinions?
> 
> Thanks,
> Volker
> 
> On Saturday, 4 April 2020 17:32:19 CEST Volker Krause wrote:
> > Thanks for the review! We are cutting it close again with the 20.04
> > deadline, but fortunately most of these findings aren't ABI-breaking :)
> > 
> > The result was discussed in more detail at the (virtual) PIM sprint,
> > summary below for the record.
> > 
> > On Saturday, 4 April 2020 16:20:21 CEST Kevin Ottens wrote:
> > > Hello,
> > > 
> > > On Saturday, 9 November 2019 12:33:54 CEST Volker Krause wrote:
> > > > during Akademy there was a request to promote KDAV from KDE PIM to
> > > > Frameworks for use by Plasma Mobile. KDAV is a framework that
> > > > implements
> > > > the CalDav/ CardDav/GroupDav protocol on top of KIO's WebDav support.
> > > > It
> > > > would be classified as a functional tier 3 framework.
> > > > 
> > > > So far we have fixed a number of obvious ABI-compatibility issues,
> > > > removed
> > > > QtXml[Patterns] usage from the public interface and relicensed GPL
> > > > parts
> > > > (apart from a bit of test code) to LGPL. The next step would be a more
> > > > thorough review to identify changes necessary before becoming a
> > > > Framework.
> > > > 
> > > > To avoid the last minute invasive changes we ended up doing for
> > > > KCalendarCore, I'd propose the following timeline:
> > > > 
> > > > - identify and implement all necessary changes to the API and ABI
> > > > until
> > > > the
> > > > 20.04 Application release (that includes the still necessary move to
> > > > the
> > > > KF5 library namespace).
> > > 
> > > I'm likely late to the party, but here is what I found by looking at
> > > KDAV
> > > 
> > > master today (first day of the KDE PIM sprint):
> > >  * There's a few private methods or Q_SLOTS that I'd hide completely by
> > > 
> > > moving them to the d-pointer, for the slots we're using type safe
> > > connects
> > > so they don't even need to be marked as slots at all;
> > 
> > Cosmetic with no ABI impact, we can do that post 20.04 still.
> > 
> > >  * Is it worth making DavCollection moveable? It's only copyable right
> > >  now;
> > 
> > Probably yes, that's new API with no ABI break, so we can do that post
> > 20.04 as well.
> > 
> > >  * We might want to do something about "ctag" in DavCollection it's a
> > >  bit
> > > 
> > > obscure as a name (and the API doc doesn't help), also it seems to not
> > > be
> > > an official standard (while being widely supported) and there's the
> > > sync-token mechanism which has a RFC (RFC6578);
> > 
> > I have no idea what ctag is (I am only doing the technical work needed to
> > turn this into a framework, I didn't write this library).
> > 
> > >  * Why isn't DavCollectionModifyJob using DavCollection somehow? (might
> > >  just
> > > 
> > > be my ignorance but I find it surprising that it is solely based on a
> > > property mechanism);
> > 
> > I think this is to be able to control which properties get changed, rather
> > than sending the full set of them.
> > 
> > >  * DavCollections(Multi)FetchJob has a mysterious "protocol" parameter
> > >  on
> > > 
> > > its collectionDiscovered signal, is it really necessary? if it has to
> > > stay,
> > > shouldn't be at least documented? or at least a safer type than int?
> > 
> > Fixed in https://phabricator.kde.org/D28564 and
> > https://phabricator.kde.org/ D28566
> > 
> > > * DavCollectionsMultiFetchJob is inconsist

Re: The KDEPIM / Akonadi situation

[Volker Krause]

On Saturday, 13 June 2020 17:35:08 CEST Adriaan de Groot wrote:
> On Saturday, 13 June 2020 09:29:36 CEST Volker Krause wrote:
> > I have finite time and prioritized what seemed to have most wide-spread
> > impact (all of Android and all of Flatpak vs. Akonadi/FreeBSD),
> 
> And, as time and circumstance permits, the PIM team prods me and/or tcberner
> to take an extra close look.
> 
> 
> 
> There is a peculiar cascade going on here, which **isn't** especially PIM-
> related.
> 
> 1) kaccounts-integration has a binary-incompatible change going on: it
> changed to
>   explicit GetCredentialsJob(Accounts::AccountId id, QObject *parent 
=
> nullptr);
> 
> from
> 
>   explicit GetCredentialsJob(const Accounts::AccountId , QObject
> *parent = nullptr);
> 
> 2) For whatever reason, **older** kaccounts-integration is installed on the
> FreeBSD builders before Akonadi builds; this puts the old headers in /usr/
> local/include
> 
> 3) I don't know if new accounts-integration builds before Akonadi; if it
> does, I don't know where it is installing its headers.
> 
> 4) When building Akonadi, it has /usr/local/include in its search path
> **ahead** of any paths that might point to the "new" accounts-integration
> headers. So it picks up the old definitions, then bails out when it tries to
> link to the new libraries.
> 
> 
> 
> I can reproduce the problem locally with kdesrc-build.
> 
> Possibly Linux CI doesn't get the same problem, because it doesn't need to
> have extra system header locations (i.e. /usr/local/include) put onto the
> search path, and so an older installed accounts-integration just lives in
> the "default bits" which are searched last.
> 
> 
> So if anything, what we're seeing here is a BIC that falls over because too
> many pieces have to move at once, on a platform that has some special
> considerations, that none of the PIM developers are on all the time. If you
> want to get on their case at all, do it for "ask [ade] or tcberner earlier",
> although in this particular case it wouldn't have sped things up: it's
> saturday afternoon, and now I have time to look into this.

Thanks Ade! It looked like Dan had fixed the build error this morning though, 
I see things being green here: https://build.kde.org/job/Applications/view/
Everything/job/akonadi/job/kf5-qt5%20FreeBSDQt5.14/ - where did I miss the 
Accounts issue?

Regards,
Volker

Re: The KDEPIM / Akonadi situation

[Volker Krause]

On Friday, 12 June 2020 23:54:19 CEST Ben Cooksley wrote:
> On Sat, Jun 13, 2020 at 7:49 AM Andras Mantia  wrote:
> > Hey,
> 
> Hi all,
> 
> >  don't want to add much as I'm not active anymore and have my share of
> 
> fault
> 
> > for not fixing certain bugs, but I'd like to reply to only one thing...
> > 
> > On Friday, June 12, 2020 6:11:31 AM EEST Nate Graham wrote:
> > > However I think there is a bigger challenge that just the technical
> > > issues. My interactions in bug reports have been quite negative, I have
> > > to say, and I don't feel like the developer culture is very welcoming
> > > right now.
> > 
> > Sorry if you had bad experience, not sure what happened, but I can assure
> 
> that
> 
> > most (or rather: all) developers I worked with in the PIM area were nice
> 
> and
> 
> > friendly.
> 
> They are however, terrible at reading emails from the CI system. To the
> point I suspect they have filters sending such mail to the trash so it is
> never seen.

sigh, not this again please... Ben, you very well know I look after Jenkins 
issues at least once a day. Here's yesterday:
(1) manually triggered a number of PIM builds that were stuck due to having 
ran in the wrong order, I'm sure the Jenkins log will confirm that if you 
don't believe me.
(2) submitted a first step towards fixing the Android failures caused by the 
anongit shutdown, https://invent.kde.org/sysadmin/ci-tooling/-/merge_requests/
78, you should know having merged that yourself even.
(3) submitted the first batch of fixes for the broken Flatpak builds due to 
the anongit shutdown, https://invent.kde.org/packaging/flatpak-kde-runtime/-/
merge_requests/13 (still needs review)

The Akonadi/FreeBSD issue persists since more than 48h, so why didn't I look 
into that the day before yesterday then? Because I was fixing the Yocto builds 
due to the anongit shutdown: 
- https://invent.kde.org/packaging/yocto-meta-kf5/-/commit/
e5e32bcb41aa3922b0885de0ac3355a36bffad80
- https://invent.kde.org/packaging/yocto-meta-kde/-/commit/
e6925a5737ab8ec2fe9dd0281b58579c3fbb74fb

> Akonadi has been in a broken state for several days now on FreeBSD. They
> have received multiple notices of this to their mailing list, and yet no
> action has been taken.
> 
> Because other software outside of PIM depends on Akonadi, the dependency
> builds for the CI system are unable to successfully finish (failing in
> Akonadi), meaning the CI system is now effectively unmaintainable on
> FreeBSD.

I am very well aware of the ripple effects such failures can have, see the 
above work on dealing with the anongit shutdown fallout.

> Continued builds for software in Extragear and Release Service are
> therefore currently dependent on the Binary Compatibility of the system not
> being broken.
> 
> Should anything happen to affect that then all of those builds will cease
> to work and be unfixable. That is a situation that I find fundamentally
> unacceptable.
> 
> This type of issue has come up numerous times before, and is one that the
> PIM developers have failed to address.
> 
> I'm therefore at a loss for options going forward and think that the only
> reasonable and viable solution in the long run will be to blacklist Akonadi
> from the CI system, and remove CI builds for everything with a hard
> dependency on it, including all of KDE PIM.

I have finite time and prioritized what seemed to have most wide-spread impact 
(all of Android and all of Flatpak vs. Akonadi/FreeBSD), as well as things 
that are most efficient for me to fix (Yocto vs. FreeBSD, having the necessary 
setup locally). If there are considerations I'm missing here you could just 
have talked to me directly, no need to resort to threats.

Regards,
Volker

[kmail2] [Bug 422325] Newer KMail crashes with HTML Mail from DHL

[Volker Krause]

https://bugs.kde.org/show_bug.cgi?id=422325

--- Comment #8 from Volker Krause  ---
Git commit 1021bb61cd28b0b18594cfc1995a3ad10e9174ea by Volker Krause.
Committed on 06/06/2020 at 08:48.
Pushed by vkrause into branch 'master'.

Add support for displaying generic Apple Wallet passes

Found for example in some emails from DHL.

M  +1-1CMakeLists.txt
M  +9-0plugins/messageviewer/bodypartformatter/pkpass/pkpass_plugin.cpp
M  +1-0plugins/messageviewer/bodypartformatter/pkpass/templates.qrc
A  +96   -0   
plugins/messageviewer/bodypartformatter/pkpass/templates/generic.html

https://invent.kde.org/pim/kdepim-addons/commit/1021bb61cd28b0b18594cfc1995a3ad10e9174ea

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmail2] [Bug 422325] Newer KMail crashes with HTML Mail from DHL

[Volker Krause]

https://bugs.kde.org/show_bug.cgi?id=422325

--- Comment #8 from Volker Krause  ---
Git commit 1021bb61cd28b0b18594cfc1995a3ad10e9174ea by Volker Krause.
Committed on 06/06/2020 at 08:48.
Pushed by vkrause into branch 'master'.

Add support for displaying generic Apple Wallet passes

Found for example in some emails from DHL.

M  +1-1CMakeLists.txt
M  +9-0plugins/messageviewer/bodypartformatter/pkpass/pkpass_plugin.cpp
M  +1-0plugins/messageviewer/bodypartformatter/pkpass/templates.qrc
A  +96   -0   
plugins/messageviewer/bodypartformatter/pkpass/templates/generic.html

https://invent.kde.org/pim/kdepim-addons/commit/1021bb61cd28b0b18594cfc1995a3ad10e9174ea

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmail2] [Bug 422325] Newer KMail crashes with HTML Mail from DHL

[Volker Krause]

https://bugs.kde.org/show_bug.cgi?id=422325

Volker Krause  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REPORTED|RESOLVED
  Latest Commit||https://invent.kde.org/pim/
   ||kdepim-addons/commit/51be4d
   ||2a71be17f66a6535f8a41450545
   ||7117939

--- Comment #7 from Volker Krause  ---
Git commit 51be4d2a71be17f66a6535f8a414505457117939 by Volker Krause.
Committed on 06/06/2020 at 08:03.
Pushed by vkrause into branch 'release/20.04'.

Fix crash when encountering pkpass types we cannot render

M  +3-0plugins/messageviewer/bodypartformatter/pkpass/pkpass_plugin.cpp

https://invent.kde.org/pim/kdepim-addons/commit/51be4d2a71be17f66a6535f8a414505457117939

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmail2] [Bug 422325] Newer KMail crashes with HTML Mail from DHL

[Volker Krause]

https://bugs.kde.org/show_bug.cgi?id=422325

Volker Krause  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REPORTED|RESOLVED
  Latest Commit||https://invent.kde.org/pim/
   ||kdepim-addons/commit/51be4d
   ||2a71be17f66a6535f8a41450545
   ||7117939

--- Comment #7 from Volker Krause  ---
Git commit 51be4d2a71be17f66a6535f8a414505457117939 by Volker Krause.
Committed on 06/06/2020 at 08:03.
Pushed by vkrause into branch 'release/20.04'.

Fix crash when encountering pkpass types we cannot render

M  +3-0plugins/messageviewer/bodypartformatter/pkpass/pkpass_plugin.cpp

https://invent.kde.org/pim/kdepim-addons/commit/51be4d2a71be17f66a6535f8a414505457117939

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmail2] [Bug 422325] Newer KMail crashes with HTML Mail from DHL

[Volker Krause]

https://bugs.kde.org/show_bug.cgi?id=422325

--- Comment #6 from Volker Krause  ---
The backtrace doesn't have line numbers, so having the email causing this (or
at least its pkpass attachment) would help a lot for reproducing this. Doesn't
need to be shared publicly, you can sent it to me directly (vkra...@kde.org).
Thanks!

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmail2] [Bug 422325] Newer KMail crashes with HTML Mail from DHL

[Volker Krause]

https://bugs.kde.org/show_bug.cgi?id=422325

--- Comment #6 from Volker Krause  ---
The backtrace doesn't have line numbers, so having the email causing this (or
at least its pkpass attachment) would help a lot for reproducing this. Doesn't
need to be shared publicly, you can sent it to me directly (vkra...@kde.org).
Thanks!

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kuserfeedback] [Bug 422227] org.kde.plasmashell Internal Server Error

[Volker Krause]

https://bugs.kde.org/show_bug.cgi?id=47

--- Comment #3 from Volker Krause  ---
Ben checked the logs, the problem seems to be that the server hits the PHP
memory limit for those two products (as they have accumulated 10+M of data by
now), and right now the full JSON response with that data is assembled in
memory.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kuserfeedback] [Bug 422227] org.kde.plasmashell Internal Server Error

[Volker Krause]

https://bugs.kde.org/show_bug.cgi?id=47

--- Comment #2 from Volker Krause  ---
Plasma and Discover show this problem, all other products seems to work fine.
Asking sysadmins for the server logs.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kuserfeedback] [Bug 422227] org.kde.plasmashell Internal Server Error

[Volker Krause]

https://bugs.kde.org/show_bug.cgi?id=47

Volker Krause  changed:

   What|Removed |Added

 CC||k...@davidedmundson.co.uk

--- Comment #1 from Volker Krause  ---
*** Bug 422348 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kuserfeedback] [Bug 422348] server replied: Internal Server Error

[Volker Krause]

https://bugs.kde.org/show_bug.cgi?id=422348

Volker Krause  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|REPORTED|RESOLVED

--- Comment #1 from Volker Krause  ---


*** This bug has been marked as a duplicate of bug 47 ***

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kuserfeedback] [Bug 418981] Violation of KDE Software Privacy Policy

[Volker Krause]

https://bugs.kde.org/show_bug.cgi?id=418981

--- Comment #9 from Volker Krause  ---
The policy is meant to be about data shared with KDE, ie. data actually sent to
the telemetry server, not about what applications do locally. If that is
unclear anywhere in the wording we can certainly improve/clarify that.

-- 
You are receiving this mail because:
You are watching all bug changes.

D29747: Deprecate AbstractBarcode::minimumSize() also for the compiler

[Volker Krause]

vkrause added a comment.


  PIM has been fully adapted meanwhile, only https://phabricator.kde.org/D29478 
missing I think.

REPOSITORY
  R280 Prison

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

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

Re: New Framework Review: KDAV

[Volker Krause]

The remaining issues that didn't change ABI anymore (movable value types, hide 
private methods/slots inside the private classes, etc) have long since been 
addressed.

I think there's two possible time slots to actually execute the move to 
frameworks now:
* ASAP, for the June release.
* For the July release, just in time for the 20.08 dependency freeze.

Opinions?

Thanks,
Volker

On Saturday, 4 April 2020 17:32:19 CEST Volker Krause wrote:
> Thanks for the review! We are cutting it close again with the 20.04
> deadline, but fortunately most of these findings aren't ABI-breaking :)
> 
> The result was discussed in more detail at the (virtual) PIM sprint, summary
> below for the record.
> 
> On Saturday, 4 April 2020 16:20:21 CEST Kevin Ottens wrote:
> > Hello,
> > 
> > On Saturday, 9 November 2019 12:33:54 CEST Volker Krause wrote:
> > > during Akademy there was a request to promote KDAV from KDE PIM to
> > > Frameworks for use by Plasma Mobile. KDAV is a framework that implements
> > > the CalDav/ CardDav/GroupDav protocol on top of KIO's WebDav support. It
> > > would be classified as a functional tier 3 framework.
> > > 
> > > So far we have fixed a number of obvious ABI-compatibility issues,
> > > removed
> > > QtXml[Patterns] usage from the public interface and relicensed GPL parts
> > > (apart from a bit of test code) to LGPL. The next step would be a more
> > > thorough review to identify changes necessary before becoming a
> > > Framework.
> > > 
> > > To avoid the last minute invasive changes we ended up doing for
> > > KCalendarCore, I'd propose the following timeline:
> > > 
> > > - identify and implement all necessary changes to the API and ABI until
> > > the
> > > 20.04 Application release (that includes the still necessary move to the
> > > KF5 library namespace).
> > 
> > I'm likely late to the party, but here is what I found by looking at KDAV
> > 
> > master today (first day of the KDE PIM sprint):
> >  * There's a few private methods or Q_SLOTS that I'd hide completely by
> > 
> > moving them to the d-pointer, for the slots we're using type safe connects
> > so they don't even need to be marked as slots at all;
> 
> Cosmetic with no ABI impact, we can do that post 20.04 still.
> 
> >  * Is it worth making DavCollection moveable? It's only copyable right
> >  now;
> 
> Probably yes, that's new API with no ABI break, so we can do that post 20.04
> as well.
> 
> >  * We might want to do something about "ctag" in DavCollection it's a bit
> > 
> > obscure as a name (and the API doc doesn't help), also it seems to not be
> > an official standard (while being widely supported) and there's the
> > sync-token mechanism which has a RFC (RFC6578);
> 
> I have no idea what ctag is (I am only doing the technical work needed to
> turn this into a framework, I didn't write this library).
> 
> >  * Why isn't DavCollectionModifyJob using DavCollection somehow? (might
> >  just
> > 
> > be my ignorance but I find it surprising that it is solely based on a
> > property mechanism);
> 
> I think this is to be able to control which properties get changed, rather
> than sending the full set of them.
> 
> >  * DavCollections(Multi)FetchJob has a mysterious "protocol" parameter on
> > 
> > its collectionDiscovered signal, is it really necessary? if it has to
> > stay,
> > shouldn't be at least documented? or at least a safer type than int?
> 
> Fixed in https://phabricator.kde.org/D28564 and https://phabricator.kde.org/
> D28566
> 
> > * DavCollectionsMultiFetchJob is inconsistent as it's not using
> > Q_DECLARE_PRIVATE;
> 
> That's due to using KJob as a base directly.
> 
> Subsequent discussion suggested this should be a KCompositeJob, David is
> taking care of this.
> 
> >  * KDAV::Error would benefit from more apidox;
> 
> Yes, not blocked by the 20.04 freeze though.
> 
> >  * Is it worth making DavItem moveable? It's only copyable right now;
> 
> See above, same as DavCollection.
> 
> >  * Same comment about etag for DavItem than the ctag one for DavCollection
> 
> See above, same as ctag.
> 
> >  * I'd be tempted to move all the protected methods of DavJobBase on its
> >  d-
> > 
> > pointer, the job subclasses would have access to them anyway, it'd make
> > sense to put them protected in the header only if we expect subclasses
> > outside of the lib (and I doubt this is actually supported);
> 
> ABI impact mitigated by https://phabricator.kde.org/D

Re: New Framework Review: KDAV

[Volker Krause]

The remaining issues that didn't change ABI anymore (movable value types, hide 
private methods/slots inside the private classes, etc) have long since been 
addressed.

I think there's two possible time slots to actually execute the move to 
frameworks now:
* ASAP, for the June release.
* For the July release, just in time for the 20.08 dependency freeze.

Opinions?

Thanks,
Volker

On Saturday, 4 April 2020 17:32:19 CEST Volker Krause wrote:
> Thanks for the review! We are cutting it close again with the 20.04
> deadline, but fortunately most of these findings aren't ABI-breaking :)
> 
> The result was discussed in more detail at the (virtual) PIM sprint, summary
> below for the record.
> 
> On Saturday, 4 April 2020 16:20:21 CEST Kevin Ottens wrote:
> > Hello,
> > 
> > On Saturday, 9 November 2019 12:33:54 CEST Volker Krause wrote:
> > > during Akademy there was a request to promote KDAV from KDE PIM to
> > > Frameworks for use by Plasma Mobile. KDAV is a framework that implements
> > > the CalDav/ CardDav/GroupDav protocol on top of KIO's WebDav support. It
> > > would be classified as a functional tier 3 framework.
> > > 
> > > So far we have fixed a number of obvious ABI-compatibility issues,
> > > removed
> > > QtXml[Patterns] usage from the public interface and relicensed GPL parts
> > > (apart from a bit of test code) to LGPL. The next step would be a more
> > > thorough review to identify changes necessary before becoming a
> > > Framework.
> > > 
> > > To avoid the last minute invasive changes we ended up doing for
> > > KCalendarCore, I'd propose the following timeline:
> > > 
> > > - identify and implement all necessary changes to the API and ABI until
> > > the
> > > 20.04 Application release (that includes the still necessary move to the
> > > KF5 library namespace).
> > 
> > I'm likely late to the party, but here is what I found by looking at KDAV
> > 
> > master today (first day of the KDE PIM sprint):
> >  * There's a few private methods or Q_SLOTS that I'd hide completely by
> > 
> > moving them to the d-pointer, for the slots we're using type safe connects
> > so they don't even need to be marked as slots at all;
> 
> Cosmetic with no ABI impact, we can do that post 20.04 still.
> 
> >  * Is it worth making DavCollection moveable? It's only copyable right
> >  now;
> 
> Probably yes, that's new API with no ABI break, so we can do that post 20.04
> as well.
> 
> >  * We might want to do something about "ctag" in DavCollection it's a bit
> > 
> > obscure as a name (and the API doc doesn't help), also it seems to not be
> > an official standard (while being widely supported) and there's the
> > sync-token mechanism which has a RFC (RFC6578);
> 
> I have no idea what ctag is (I am only doing the technical work needed to
> turn this into a framework, I didn't write this library).
> 
> >  * Why isn't DavCollectionModifyJob using DavCollection somehow? (might
> >  just
> > 
> > be my ignorance but I find it surprising that it is solely based on a
> > property mechanism);
> 
> I think this is to be able to control which properties get changed, rather
> than sending the full set of them.
> 
> >  * DavCollections(Multi)FetchJob has a mysterious "protocol" parameter on
> > 
> > its collectionDiscovered signal, is it really necessary? if it has to
> > stay,
> > shouldn't be at least documented? or at least a safer type than int?
> 
> Fixed in https://phabricator.kde.org/D28564 and https://phabricator.kde.org/
> D28566
> 
> > * DavCollectionsMultiFetchJob is inconsistent as it's not using
> > Q_DECLARE_PRIVATE;
> 
> That's due to using KJob as a base directly.
> 
> Subsequent discussion suggested this should be a KCompositeJob, David is
> taking care of this.
> 
> >  * KDAV::Error would benefit from more apidox;
> 
> Yes, not blocked by the 20.04 freeze though.
> 
> >  * Is it worth making DavItem moveable? It's only copyable right now;
> 
> See above, same as DavCollection.
> 
> >  * Same comment about etag for DavItem than the ctag one for DavCollection
> 
> See above, same as ctag.
> 
> >  * I'd be tempted to move all the protected methods of DavJobBase on its
> >  d-
> > 
> > pointer, the job subclasses would have access to them anyway, it'd make
> > sense to put them protected in the header only if we expect subclasses
> > outside of the lib (and I doubt this is actually supported);
> 
> ABI impact mitigated by https://phabricator.kde.org/D

Re: KEmoticons, emoticons kcm

[Volker Krause]

On Saturday, 23 May 2020 02:49:57 CEST Aleix Pol wrote:
> I was looking through some Plasma code and I saw that we have some
> fairly old emoticons KCM using KF5Emoticons.
> 
> Now while I know why this exists, it feels like it's more of a thing
> of the past from when people wrote :) instead of . While keeping it
> around for the few apps that might still use it (ktp? kopete?) could
> make sense, I'm afraid it's probably making it confusing for the users
> who expect this to actually allow them to customise their  but
> won't.
> 
> Do you think it would make sense to deprecate the framework and remove the
> KCM?

Absolutely! 

There's some discussion on this topic in https://phabricator.kde.org/T11585 
already. While direct usage of KEmoticons in applications is rare, there is a 
"backdoor dependency" via a KCoreAddons plug-in it provides.

Regards,
Volker

Re: KEmoticons, emoticons kcm

[Volker Krause]

On Saturday, 23 May 2020 02:49:57 CEST Aleix Pol wrote:
> I was looking through some Plasma code and I saw that we have some
> fairly old emoticons KCM using KF5Emoticons.
> 
> Now while I know why this exists, it feels like it's more of a thing
> of the past from when people wrote :) instead of . While keeping it
> around for the few apps that might still use it (ktp? kopete?) could
> make sense, I'm afraid it's probably making it confusing for the users
> who expect this to actually allow them to customise their  but
> won't.
> 
> Do you think it would make sense to deprecate the framework and remove the
> KCM?

Absolutely! 

There's some discussion on this topic in https://phabricator.kde.org/T11585 
already. While direct usage of KEmoticons in applications is rare, there is a 
"backdoor dependency" via a KCoreAddons plug-in it provides.

Regards,
Volker

D29358: Implement lock-screen visibility control on Android

[Volker Krause]

vkrause closed this revision.

REPOSITORY
  R289 KNotifications

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

To: vkrause, nicolasfella
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29358: Implement lock-screen visibility control on Android

[Volker Krause]

vkrause updated this revision to Diff 83104.
vkrause added a comment.


  Rename visibility hint.

REPOSITORY
  R289 KNotifications

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29358?vs=81734=83104

BRANCH
  pending

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

AFFECTED FILES
  src/android/org/kde/knotifications/KNotification.java
  src/android/org/kde/knotifications/NotifyByAndroid.java
  src/notifybyandroid.cpp

To: vkrause, nicolasfella
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29358: Implement lock-screen visibility control on Android

[Volker Krause]

vkrause added a comment.


  ping?

REPOSITORY
  R289 KNotifications

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

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

D29335: Implement notification grouping on Android

[Volker Krause]

This revision was automatically updated to reflect the committed changes.
Closed by commit R289:942bddded289: Implement notification grouping on Android 
(authored by vkrause).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D29335?vs=81731=83063#toc

REPOSITORY
  R289 KNotifications

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29335?vs=81731=83063

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

AFFECTED FILES
  src/android/org/kde/knotifications/KNotification.java
  src/android/org/kde/knotifications/NotifyByAndroid.java
  src/notifybyandroid.cpp

To: vkrause, nicolasfella
Cc: nicolasfella, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, 
bruns

D29357: Display rich text notification messages on Android

[Volker Krause]

This revision was automatically updated to reflect the committed changes.
Closed by commit R289:c14be41192d2: Display rich text notification messages on 
Android (authored by vkrause).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D29357?vs=82566=83046#toc

REPOSITORY
  R289 KNotifications

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29357?vs=82566=83046

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

AFFECTED FILES
  src/android/org/kde/knotifications/KNotification.java
  src/android/org/kde/knotifications/NotifyByAndroid.java
  src/notifybyandroid.cpp

To: vkrause, tfella
Cc: z3ntu, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D27989: Add a new set of barcode size functions

[Volker Krause]

vkrause added a comment.


  In D27989#670416 , @kossebau wrote:
  
  > > minimumSize() becomes deprecated by this, the deprecation macros will
  > >  follow once the current users have been adjusted.
  >
  > IMHO you should add the macros from the start, otherwise it will be only 
forgotten later, as there is no mechanism to remind you. And without compiler 
warnings all the remaining users might never learn about it.
  >
  > I would expect you have prepared patches for some known users already to 
testdrive the new API for usefulness, so the set of remaining users (in KDE 
spheres) should be already small. And those not yet withzout a patch, what 
would be the plan to care for them? In the end it needs to compiler warnings to 
get other people in the game. After all API is not deprecated without a reason. 
Being too gentle with warnings does not help anyone in the end.
  
  
  There's two remaining users in everything covered by lxr, the Plasma 
clipboard (patch in review: https://phabricator.kde.org/D29478) and KDE PIM 
(which now depends on a sufficiently new KF5 version to actually do the 
migration). Both ways can be argued of course, I optimized for "helps me" (the 
warnings for things I can't change yet don't), and "migration is my problem" 
rather than "migration is somebody else's problem" (which is my understanding 
of how we are supposed to be doing KF deprecations to ease the 6 transition).

REPOSITORY
  R280 Prison

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

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

D29357: Display rich text notification messages on Android

[Volker Krause]

vkrause retitled this revision from "Display rich text notification messages on 
Android (API level 24+)" to "Display rich text notification messages on 
Android".

REPOSITORY
  R289 KNotifications

BRANCH
  rich-text

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

To: vkrause, tfella
Cc: z3ntu, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29357: Display rich text notification messages on Android (API level 24+)

[Volker Krause]

vkrause updated this revision to Diff 82566.
vkrause added a comment.


  Support API level < 24 as well.

REPOSITORY
  R289 KNotifications

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29357?vs=81729=82566

BRANCH
  rich-text

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

AFFECTED FILES
  src/android/org/kde/knotifications/KNotification.java
  src/android/org/kde/knotifications/NotifyByAndroid.java
  src/notifybyandroid.cpp

To: vkrause, tfella
Cc: z3ntu, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29575: holidayregion.cpp - provide translatable strings for the German regions.

[Volker Krause]

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

REPOSITORY
  R175 KHolidays

BRANCH
  master

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

To: winterz, vkrause
Cc: ltoscano, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29274: ECMGeneratePriFile: make the pri files relocatable

[Volker Krause]

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

REPOSITORY
  R240 Extra CMake Modules

BRANCH
  master

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

To: dfaure, vatra, kfunk, apol, vkrause
Cc: ablu, kossebau, kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, 
bencreasy, michaelh, ngraham, bruns

D29274: ECMGeneratePriFile: make the pri files relocatable

[Volker Krause]

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

REPOSITORY
  R240 Extra CMake Modules

BRANCH
  master

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

To: dfaure, vatra, kfunk, apol, vkrause
Cc: ablu, kossebau, kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, 
bencreasy, michaelh, ngraham, bruns

D29342: Implement support for notification urgency on Android

[Volker Krause]

This revision was automatically updated to reflect the committed changes.
Closed by commit R289:9a13dd26d1de: Implement support for notification urgency 
on Android (authored by vkrause).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D29342?vs=81695=82227#toc

REPOSITORY
  R289 KNotifications

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29342?vs=81695=82227

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

AFFECTED FILES
  src/android/org/kde/knotifications/KNotification.java
  src/android/org/kde/knotifications/NotifyByAndroid.java
  src/notifybyandroid.cpp

To: vkrause, nicolasfella
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

[frameworks-kuserfeedback] [Bug 420955] KUserFeedback components are hard (not optional) runtime dependency once compiled in

[Volker Krause]

https://bugs.kde.org/show_bug.cgi?id=420955

Volker Krause  changed:

   What|Removed |Added

 Status|CONFIRMED   |RESOLVED
 Resolution|--- |NOT A BUG

--- Comment #2 from Volker Krause  ---
Not practically doable, at best you could move the actual submission to a small
plugin, but that still keeps the bulk of the framework compile-time.

-- 
You are receiving this mail because:
You are watching all bug changes.

D29478: [Clipboard Plasmoid] Port to Prison QML import

[Volker Krause]

vkrause added a comment.


  Technically this looks fine from the Prison POV. Whether the barcode type 
selection makes sense beyond "because we can" I'm not sure about though (in 
particular the 1D codes seem to be of questionable use here), but then again 
that's not something introduced by this patch anyway.

REPOSITORY
  R120 Plasma Workspace

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

To: broulik, #plasma, vkrause
Cc: ngraham, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, 
jraleigh, zachus, fbampaloukas, ragreen, ZrenBot, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D29415: Add holiday file for DE-BE (Germany/Berlin)

[Volker Krause]

This revision was automatically updated to reflect the committed changes.
Closed by commit R175:c39d1eb12217: Add holiday file for DE-BE (Germany/Berlin) 
(authored by vkrause).

REPOSITORY
  R175 KHolidays

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29415?vs=81905=81999

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

AFFECTED FILES
  holidays/holidays.qrc
  holidays/plan2/holiday_de-be_de

To: vkrause, winterz
Cc: winterz, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29415: Add holiday file for DE-BE (Germany/Berlin)

[Volker Krause]

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

REVISION SUMMARY
  The generic DE file doesn't really work anymore since Berlin got creative
  in adding non-standard public holidays.

REPOSITORY
  R175 KHolidays

BRANCH
  master

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

AFFECTED FILES
  holidays/holidays.qrc
  holidays/plan2/holiday_de-be_de

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

D29358: Implement lock-screen visibility control on Android

[Volker Krause]

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

REVISION SUMMARY
  This is only the backend part, lacking a proper frontend API this is
  using a custom hint for now. Android knows three levels for this:
  
  - public: visible completely on the lock screen
  - private: lock screen only shows that $app has notifications
  - secret: nothing shown on the lock screen at all

REPOSITORY
  R289 KNotifications

BRANCH
  pending

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

AFFECTED FILES
  src/android/org/kde/knotifications/KNotification.java
  src/android/org/kde/knotifications/NotifyByAndroid.java
  src/notifybyandroid.cpp

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

D29335: Implement notification grouping on Android

[Volker Krause]

vkrause updated this revision to Diff 81731.
vkrause added a comment.


  Replace the simple ref count with a full child id tracking.
  
  The ref count got out of sync when an existing notification is updated, using 
a set fixes that.

REPOSITORY
  R289 KNotifications

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29335?vs=81725=81731

BRANCH
  grouping

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

AFFECTED FILES
  src/android/org/kde/knotifications/KNotification.java
  src/android/org/kde/knotifications/NotifyByAndroid.java
  src/notifybyandroid.cpp

To: vkrause, nicolasfella
Cc: nicolasfella, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, 
bruns

D29335: Implement notification grouping on Android

[Volker Krause]

vkrause added a comment.


  Still not good enough, updating existing notfication messes up the 
refcounter, resulting still in leftover group elements.

REPOSITORY
  R289 KNotifications

BRANCH
  grouping

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

To: vkrause, nicolasfella
Cc: nicolasfella, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, 
bruns

D29357: Display rich text notification messages on Android (API level 24+)

[Volker Krause]

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

REPOSITORY
  R289 KNotifications

BRANCH
  pending

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

AFFECTED FILES
  src/android/org/kde/knotifications/KNotification.java
  src/android/org/kde/knotifications/NotifyByAndroid.java
  src/notifybyandroid.cpp

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

D29357: Display rich text notification messages on Android (API level 24+)

[Volker Krause]

vkrause added a comment.


  Example: F8278136: Screenshot_20200502_112835.PNG 


REPOSITORY
  R289 KNotifications

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

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

D29335: Implement notification grouping on Android

[Volker Krause]

vkrause updated this revision to Diff 81725.
vkrause added a comment.


  Explicitly track if notification groups are still in use.
  
  This fixes group summaries staying active when we explicitly
  close a notification, rather then having the user or system
  dismiss it.

REPOSITORY
  R289 KNotifications

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29335?vs=81678=81725

BRANCH
  grouping

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

AFFECTED FILES
  src/android/org/kde/knotifications/KNotification.java
  src/android/org/kde/knotifications/NotifyByAndroid.java
  src/notifybyandroid.cpp

To: vkrause, nicolasfella
Cc: nicolasfella, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, 
bruns

D29335: Implement notification grouping on Android

[Volker Krause]

vkrause added a comment.


  This isn't good to go yet, there are corner cases where the group summary 
item stays around after closing the last notification, working on fixing this.

REPOSITORY
  R289 KNotifications

BRANCH
  master

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

To: vkrause, nicolasfella
Cc: nicolasfella, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, 
bruns

D29339: Implement updating of notifications on Android

[Volker Krause]

This revision was automatically updated to reflect the committed changes.
Closed by commit R289:c5688295e45f: Implement updating of notifications on 
Android (authored by vkrause).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D29339?vs=81686=81722#toc

REPOSITORY
  R289 KNotifications

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29339?vs=81686=81722

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

AFFECTED FILES
  src/notifybyandroid.cpp
  src/notifybyandroid.h

To: vkrause, nicolasfella
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29323: Handle multi-line and rich-text notifications on Android

[Volker Krause]

This revision was automatically updated to reflect the committed changes.
Closed by commit R289:9bfd98a3d3da: Handle multi-line and rich-text 
notifications on Android (authored by vkrause).

REPOSITORY
  R289 KNotifications

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29323?vs=81657=81721

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

AFFECTED FILES
  src/android/org/kde/knotifications/NotifyByAndroid.java
  src/notifybyandroid.cpp

To: vkrause, nicolasfella
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29342: Implement support for notification urgency on Android

[Volker Krause]

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

REVISION SUMMARY
  While the notification levels map nicely, the behavior on Android with
  API level 26 or higher is slightly different from what one might expect:
  The urgency is configured on the notification channel the first time it
  is created, and then persisted together with the user's notification
  settings. That means that changes to the notification level after this
  has been used for the first time have no effect.

REPOSITORY
  R289 KNotifications

BRANCH
  master

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

AFFECTED FILES
  src/android/org/kde/knotifications/KNotification.java
  src/android/org/kde/knotifications/NotifyByAndroid.java
  src/notifybyandroid.cpp

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

D29339: Implement updating of notifications on Android

[Volker Krause]

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

REPOSITORY
  R289 KNotifications

BRANCH
  master

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

AFFECTED FILES
  src/notifybyandroid.cpp
  src/notifybyandroid.h

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

D29335: Implement notification grouping on Android

[Volker Krause]

vkrause added inline comments.

INLINE COMMENTS

> nicolasfella wrote in NotifyByAndroid.java:171
> Please use 
> https://developer.android.com/reference/android/os/Build.VERSION_CODES 
> instead of hardcoding numbers

That seems counter-productive to me, as the Android API documentation always 
speaks about API level numbers, so you'd need to do an additional translation 
to/from the letters in your head. So for that I find "26" more useful here than 
"O". It's also consistent with the rest of the code in this file.

REPOSITORY
  R289 KNotifications

BRANCH
  master

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

To: vkrause, nicolasfella
Cc: nicolasfella, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, 
bruns

D29335: Implement notification grouping on Android

[Volker Krause]

vkrause added a comment.


  Collapsed: F8276057: Screenshot_20200501_161952.PNG 

  Expanded: F8276059: Screenshot_20200501_162043.PNG 


REPOSITORY
  R289 KNotifications

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

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

D29335: Implement notification grouping on Android

[Volker Krause]

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

REVISION SUMMARY
  This is available starting at API level 20, which is below our minimal
  requirement. Grouping can be disabled by the already existing SkipGrouping
  flag.
  
  When enabled this puts all notifications from the same eventId in a group,
  which makes the display more compact by removing the otherwise duplicated
  app name.

REPOSITORY
  R289 KNotifications

BRANCH
  master

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

AFFECTED FILES
  src/android/org/kde/knotifications/KNotification.java
  src/android/org/kde/knotifications/NotifyByAndroid.java
  src/notifybyandroid.cpp

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

D29323: Handle multi-line and rich-text notifications on Android

[Volker Krause]

vkrause added a comment.


  F8275264: Screenshot_20200501_124105.PNG 


REPOSITORY
  R289 KNotifications

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

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

D29323: Handle multi-line and rich-text notifications on Android

[Volker Krause]

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

REVISION SUMMARY
  By default only a single line of the notification message is shown,
  for making longer messages readable we need to use the BigTextStyle
  to get expandable multi-line messages. In the single-line case this
  behaves as before.
  
  According to the documentation BigTextStyle also should enable rich
  text support, however that didn't seem to work here, so for now we
  strip out rich text to not show raw HTML tags.

REPOSITORY
  R289 KNotifications

BRANCH
  master

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

AFFECTED FILES
  src/android/org/kde/knotifications/NotifyByAndroid.java
  src/notifybyandroid.cpp

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

D29268: [WIP] Add Date/Time dialog

[Volker Krause]

vkrause added a comment.


  There might be ways around the native function registration issue from the 
QML thread, e.g. by using the alternative approach of exported (mangled) 
symbols instead: 
https://docs.oracle.com/javase/1.5.0/docs/guide/jni/spec/design.html -> 
"Loading and Linking Native Methods".

REPOSITORY
  R1047 Kirigami Addons

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

To: nicolasfella, davidedmundson, vkrause, broulik
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, 
fbampaloukas, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D29079: android: include the architecture on the apk name

[Volker Krause]

vkrause added a comment.


  +1, I can't judge the impact on the subsequent pipeline though, such as the 
fdroid repo handling.

REPOSITORY
  R240 Extra CMake Modules

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

To: apol, #android, #frameworks
Cc: vkrause, kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, 
bencreasy, michaelh, ngraham, bruns

D29079: android: include the architecture on the apk name

[Volker Krause]

vkrause added a comment.


  +1, I can't judge the impact on the subsequent pipeline though, such as the 
fdroid repo handling.

REPOSITORY
  R240 Extra CMake Modules

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

To: apol, #android, #frameworks
Cc: vkrause, kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, 
bencreasy, michaelh, ngraham, bruns

D28834: Add metadata properties to calendar

[Volker Krause]

vkrause added a comment.


  In D28834#648405 , @winterz wrote:
  
  > I don't know how things are done in frameworks but it seems to me that the 
KF5_VERSION (see top of kcalendarcore/CMakeLists.txt) needs to become 5.70.0 now
  
  
  This is handled automatically, no need to change this.

INLINE COMMENTS

> calendar.h:101
> +*/
> +enum CalendarType
> +{

As already noted in the previous review, "type" isn't the best naming for 
something that is about access control/permission IMHO.

A possible alternative name could be something like "AccessMode", or maybe even 
just bool isReadOnly.

REPOSITORY
  R172 KCalendar Core

BRANCH
  props

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

To: nicolasfella, #frameworks, #kde_pim, vkrause, winterz
Cc: winterz, kde-pim, fbampaloukas, dcaliste, dvasin, rodsevich, vkrause, 
mlaurent, knauss, dvratil

[frameworks-kio] [Bug 279664] [KRun] Use EFF's rule set from HTTPS Everywhere

[Volker Krause]

https://bugs.kde.org/show_bug.cgi?id=279664

--- Comment #6 from Volker Krause  ---
Certainly interesting, it could complement HSTS for hosts not supporting that
yet. And yes, this is something you'd want to apply to all user-entered URLs,
not limited to a specific application. I'm not so sure about all HTTP
connections in general though, ie. probably something you want on top of the
existing HTTP stacks, not integrated into them? Also, these rulesets seem huge,
so we also have to keep an eye on the performance impact of this.

-- 
You are receiving this mail because:
You are watching all bug changes.

D28400: [AdvancedQueryParser] Move semantic handling of tokens to SearchStore

[Volker Krause]

vkrause added inline comments.

INLINE COMMENTS

> bruns wrote in searchstore.cpp:82
> Thanks for the heads-up.
> 
> As you have noticed, the message is vague, so someone with access to one of 
> the affected systems should test it and submit a review.

I don't have either of those here to test it for sure, but I have fixed similar 
errors elsewhere recently for those platforms by just adding the  
include, so I think @kossebau is right.

REPOSITORY
  R293 Baloo

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

To: bruns, #baloo, ngraham
Cc: vkrause, bcooksley, kossebau, kde-frameworks-devel, hurikhan77, lots0logs, 
LeGast00n, cblack, fbampaloukas, GB_2, domson, ashaposhnikov, michaelh, 
astippich, spoorun, ngraham, bruns, abrahams

[kmail2] [Bug 409001] when opened message (incapsulated by outlook) kmail crashes

[Volker Krause]

https://bugs.kde.org/show_bug.cgi?id=409001

--- Comment #17 from Volker Krause  ---
wow, nice find, that's a nasty one

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmail2] [Bug 409001] when opened message (incapsulated by outlook) kmail crashes

[Volker Krause]

https://bugs.kde.org/show_bug.cgi?id=409001

--- Comment #17 from Volker Krause  ---
wow, nice find, that's a nasty one

-- 
You are receiving this mail because:
You are watching all bug changes.

[Akonadi] [Bug 416813] Crash on startup

[Volker Krause]

https://bugs.kde.org/show_bug.cgi?id=416813

Volker Krause  changed:

   What|Removed |Added

 CC||vkra...@kde.org
 Resolution|--- |FIXED
 Status|REPORTED|RESOLVED

--- Comment #1 from Volker Krause  ---
Fixed in messagelib 20.04 branch.

-- 
You are receiving this mail because:
You are watching all bug changes.

[Akonadi] [Bug 416813] Crash on startup

[Volker Krause]

https://bugs.kde.org/show_bug.cgi?id=416813

Volker Krause  changed:

   What|Removed |Added

 CC||vkra...@kde.org
 Resolution|--- |FIXED
 Status|REPORTED|RESOLVED

--- Comment #1 from Volker Krause  ---
Fixed in messagelib 20.04 branch.

-- 
You are receiving this mail because:
You are the assignee for the bug.

D28577: Add StatusBarExtension(KParts::Part *) overloaded constructor.

[Volker Krause]

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

REPOSITORY
  R306 KParts

BRANCH
  master

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

To: dfaure, vkrause, aacid, cgiboudeaux, kossebau
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

Re: New Framework Review: KDAV

[Volker Krause]

Thanks for the review! We are cutting it close again with the 20.04 deadline, 
but fortunately most of these findings aren't ABI-breaking :)

The result was discussed in more detail at the (virtual) PIM sprint, summary 
below for the record.

On Saturday, 4 April 2020 16:20:21 CEST Kevin Ottens wrote:
> Hello,
> 
> On Saturday, 9 November 2019 12:33:54 CEST Volker Krause wrote:
> > during Akademy there was a request to promote KDAV from KDE PIM to
> > Frameworks for use by Plasma Mobile. KDAV is a framework that implements
> > the CalDav/ CardDav/GroupDav protocol on top of KIO's WebDav support. It
> > would be classified as a functional tier 3 framework.
> > 
> > So far we have fixed a number of obvious ABI-compatibility issues, removed
> > QtXml[Patterns] usage from the public interface and relicensed GPL parts
> > (apart from a bit of test code) to LGPL. The next step would be a more
> > thorough review to identify changes necessary before becoming a Framework.
> > 
> > To avoid the last minute invasive changes we ended up doing for
> > KCalendarCore, I'd propose the following timeline:
> > 
> > - identify and implement all necessary changes to the API and ABI until
> > the
> > 20.04 Application release (that includes the still necessary move to the
> > KF5 library namespace).
> 
> I'm likely late to the party, but here is what I found by looking at KDAV
> master today (first day of the KDE PIM sprint):
>  * There's a few private methods or Q_SLOTS that I'd hide completely by
> moving them to the d-pointer, for the slots we're using type safe connects
> so they don't even need to be marked as slots at all;

Cosmetic with no ABI impact, we can do that post 20.04 still.

>  * Is it worth making DavCollection moveable? It's only copyable right now;

Probably yes, that's new API with no ABI break, so we can do that post 20.04 
as well.

>  * We might want to do something about "ctag" in DavCollection it's a bit
> obscure as a name (and the API doc doesn't help), also it seems to not be an
> official standard (while being widely supported) and there's the sync-token
> mechanism which has a RFC (RFC6578);

I have no idea what ctag is (I am only doing the technical work needed to turn 
this into a framework, I didn't write this library).

>  * Why isn't DavCollectionModifyJob using DavCollection somehow? (might just
> be my ignorance but I find it surprising that it is solely based on a
> property mechanism);

I think this is to be able to control which properties get changed, rather 
than sending the full set of them.

>  * DavCollections(Multi)FetchJob has a mysterious "protocol" parameter on
> its collectionDiscovered signal, is it really necessary? if it has to stay,
> shouldn't be at least documented? or at least a safer type than int? 

Fixed in https://phabricator.kde.org/D28564 and https://phabricator.kde.org/
D28566

> * DavCollectionsMultiFetchJob is inconsistent as it's not using
> Q_DECLARE_PRIVATE;

That's due to using KJob as a base directly.

Subsequent discussion suggested this should be a KCompositeJob, David is 
taking care of this.

>  * KDAV::Error would benefit from more apidox;

Yes, not blocked by the 20.04 freeze though.

>  * Is it worth making DavItem moveable? It's only copyable right now;

See above, same as DavCollection.

>  * Same comment about etag for DavItem than the ctag one for DavCollection

See above, same as ctag.

>  * I'd be tempted to move all the protected methods of DavJobBase on its d-
> pointer, the job subclasses would have access to them anyway, it'd make
> sense to put them protected in the header only if we expect subclasses
> outside of the lib (and I doubt this is actually supported);

ABI impact mitigated by https://phabricator.kde.org/D28562 so we can clean 
this up after 20.04.

>  * It needs to decide between Qt smart pointers or STL ones I think, found a
> bit of both so far (I'd lean toward STL ones but maybe that's just me); 

Also fixed by https://phabricator.kde.org/D28562.

> * Make DavUrl moveable?

See above, same as DavCollection and DavItem.

>  * EtagCache probably shouldn't have anything protected, also, why is it a
> QObject at all?

This is why: https://lxr.kde.org/source/kde/pim/kdepim-runtime/resources/dav/
resource/akonadietagcache.cpp

>  * Are we sure we want to return a QLatin1String in ProtocolInfo? this
> strike me as an odd choice.

Fixed in https://phabricator.kde.org/D28563.

> Overall apidox would likely need a big pass of cleanups as well.

> I think that's it from me.

I hope we managed to address everything on short notice that would require ABI 
breaks after the 20.04 release (and thus cause a delay of the frameworks move 
Volker

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

Re: New Framework Review: KDAV

[Volker Krause]

Thanks for the review! We are cutting it close again with the 20.04 deadline, 
but fortunately most of these findings aren't ABI-breaking :)

The result was discussed in more detail at the (virtual) PIM sprint, summary 
below for the record.

On Saturday, 4 April 2020 16:20:21 CEST Kevin Ottens wrote:
> Hello,
> 
> On Saturday, 9 November 2019 12:33:54 CEST Volker Krause wrote:
> > during Akademy there was a request to promote KDAV from KDE PIM to
> > Frameworks for use by Plasma Mobile. KDAV is a framework that implements
> > the CalDav/ CardDav/GroupDav protocol on top of KIO's WebDav support. It
> > would be classified as a functional tier 3 framework.
> > 
> > So far we have fixed a number of obvious ABI-compatibility issues, removed
> > QtXml[Patterns] usage from the public interface and relicensed GPL parts
> > (apart from a bit of test code) to LGPL. The next step would be a more
> > thorough review to identify changes necessary before becoming a Framework.
> > 
> > To avoid the last minute invasive changes we ended up doing for
> > KCalendarCore, I'd propose the following timeline:
> > 
> > - identify and implement all necessary changes to the API and ABI until
> > the
> > 20.04 Application release (that includes the still necessary move to the
> > KF5 library namespace).
> 
> I'm likely late to the party, but here is what I found by looking at KDAV
> master today (first day of the KDE PIM sprint):
>  * There's a few private methods or Q_SLOTS that I'd hide completely by
> moving them to the d-pointer, for the slots we're using type safe connects
> so they don't even need to be marked as slots at all;

Cosmetic with no ABI impact, we can do that post 20.04 still.

>  * Is it worth making DavCollection moveable? It's only copyable right now;

Probably yes, that's new API with no ABI break, so we can do that post 20.04 
as well.

>  * We might want to do something about "ctag" in DavCollection it's a bit
> obscure as a name (and the API doc doesn't help), also it seems to not be an
> official standard (while being widely supported) and there's the sync-token
> mechanism which has a RFC (RFC6578);

I have no idea what ctag is (I am only doing the technical work needed to turn 
this into a framework, I didn't write this library).

>  * Why isn't DavCollectionModifyJob using DavCollection somehow? (might just
> be my ignorance but I find it surprising that it is solely based on a
> property mechanism);

I think this is to be able to control which properties get changed, rather 
than sending the full set of them.

>  * DavCollections(Multi)FetchJob has a mysterious "protocol" parameter on
> its collectionDiscovered signal, is it really necessary? if it has to stay,
> shouldn't be at least documented? or at least a safer type than int? 

Fixed in https://phabricator.kde.org/D28564 and https://phabricator.kde.org/
D28566

> * DavCollectionsMultiFetchJob is inconsistent as it's not using
> Q_DECLARE_PRIVATE;

That's due to using KJob as a base directly.

Subsequent discussion suggested this should be a KCompositeJob, David is 
taking care of this.

>  * KDAV::Error would benefit from more apidox;

Yes, not blocked by the 20.04 freeze though.

>  * Is it worth making DavItem moveable? It's only copyable right now;

See above, same as DavCollection.

>  * Same comment about etag for DavItem than the ctag one for DavCollection

See above, same as ctag.

>  * I'd be tempted to move all the protected methods of DavJobBase on its d-
> pointer, the job subclasses would have access to them anyway, it'd make
> sense to put them protected in the header only if we expect subclasses
> outside of the lib (and I doubt this is actually supported);

ABI impact mitigated by https://phabricator.kde.org/D28562 so we can clean 
this up after 20.04.

>  * It needs to decide between Qt smart pointers or STL ones I think, found a
> bit of both so far (I'd lean toward STL ones but maybe that's just me); 

Also fixed by https://phabricator.kde.org/D28562.

> * Make DavUrl moveable?

See above, same as DavCollection and DavItem.

>  * EtagCache probably shouldn't have anything protected, also, why is it a
> QObject at all?

This is why: https://lxr.kde.org/source/kde/pim/kdepim-runtime/resources/dav/
resource/akonadietagcache.cpp

>  * Are we sure we want to return a QLatin1String in ProtocolInfo? this
> strike me as an odd choice.

Fixed in https://phabricator.kde.org/D28563.

> Overall apidox would likely need a big pass of cleanups as well.

> I think that's it from me.

I hope we managed to address everything on short notice that would require ABI 
breaks after the 20.04 release (and thus cause a delay of the frameworks move 
Volker

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

D27595: Watch for language change events, and forward those to the QML engine

[Volker Krause]

vkrause added subscribers: broulik, davidedmundson.
vkrause added a comment.


  In D27595#636543 , @rikmills wrote:
  
  > git bisect also shows that this crashes the virtual desktop and regional 
settings KCM in Kubuntu 20.04
  
  
  I haven't seen a backtrace for this, but from what I understood from the chat 
backlog this is triggering a QML bug (?) due to the re-evaluation of qsTr() 
with 5.12, rather than actually crashing in the code of this patch? If so, I 
see three options:
  
  - ifdef the connect() call in initializeEngine() for Qt 5.12, breaking 
translations in that version only.
  - Replace this patch by the alternative approach proposed in D25984 
 for fixing translations, and see if that 
has less side effects.
  - Revert this entirely and break translations
  
  @mart @davidedmundson @broulik?

REPOSITORY
  R169 Kirigami

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

To: vkrause, mart
Cc: davidedmundson, broulik, rikmills, ngraham, apol, plasma-devel, 
fbampaloukas, GB_2, domson, dkardarakos, ahiemstra, mart

D25984: Load translations

[Volker Krause]

vkrause added a comment.


  In D25984#589426 , @mart wrote:
  
  > ping, what's the current status of this?
  
  
  There's also https://phabricator.kde.org/D27595, which might address the 
same/a similar issue.

REPOSITORY
  R169 Kirigami

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

To: broulik, #kirigami, #frameworks, kossebau, aacid
Cc: vkrause, mart, davidedmundson, plasma-devel, fbampaloukas, GB_2, domson, 
dkardarakos, ngraham, apol, ahiemstra

D25984: Load translations

[Volker Krause]

vkrause added a comment.


  In D25984#589426 , @mart wrote:
  
  > ping, what's the current status of this?
  
  
  There's also https://phabricator.kde.org/D27595, which might address the 
same/a similar issue.

REPOSITORY
  R169 Kirigami

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

To: broulik, #kirigami, #frameworks, kossebau, aacid
Cc: vkrause, mart, davidedmundson, plasma-devel, fbampaloukas, GB_2, domson, 
dkardarakos, ngraham, apol, ahiemstra

D28030: Also expose the true minimum size to QML

[Volker Krause]

This revision was automatically updated to reflect the committed changes.
Closed by commit R280:e0dec83dd692: Also expose the true minimum size to QML 
(authored by vkrause).

REPOSITORY
  R280 Prison

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D28030?vs=77578=77650

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

AFFECTED FILES
  src/quick/barcodequickitem.cpp
  src/quick/barcodequickitem.h
  tests/barcode.qml

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

D27989: Add a new set of barcode size functions

[Volker Krause]

This revision was automatically updated to reflect the committed changes.
Closed by commit R280:838f886c380f: Add a new set of barcode size functions 
(authored by vkrause).

REPOSITORY
  R280 Prison

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27989?vs=77441=77647

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

AFFECTED FILES
  autotests/aztecbarcodetest.cpp
  autotests/code128barcodetest.cpp
  src/lib/abstractbarcode.cpp
  src/lib/abstractbarcode.h
  src/quick/barcodequickitem.cpp

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

D27952: Simplify minimum size handling

[Volker Krause]

This revision was automatically updated to reflect the committed changes.
Closed by commit R280:0d64bdd22e7c: Simplify minimum size handling (authored by 
vkrause).

REPOSITORY
  R280 Prison

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27952?vs=77611=77612

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

AFFECTED FILES
  src/lib/abstractbarcode.cpp
  src/lib/abstractbarcode.h
  src/lib/aztecbarcode.cpp
  src/lib/code128barcode.cpp
  src/lib/code39barcode.cpp
  src/lib/code93barcode.cpp
  src/lib/datamatrixbarcode.cpp
  src/lib/qrcodebarcode.cpp

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

D27952: Simplify minimum size handling

[Volker Krause]

vkrause updated this revision to Diff 77611.
vkrause added a comment.


  Rebase and bump version numbers.

REPOSITORY
  R280 Prison

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27952?vs=77302=77611

BRANCH
  arcpatch-D27952

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

AFFECTED FILES
  src/lib/abstractbarcode.cpp
  src/lib/abstractbarcode.h
  src/lib/aztecbarcode.cpp
  src/lib/code128barcode.cpp
  src/lib/code39barcode.cpp
  src/lib/code93barcode.cpp
  src/lib/datamatrixbarcode.cpp
  src/lib/qrcodebarcode.cpp

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

D27909: Move barcode image scaling logic to AbstractBarcode

[Volker Krause]

This revision was automatically updated to reflect the committed changes.
Closed by commit R280:ea1f6c1abeb0: Move barcode image scaling logic to 
AbstractBarcode (authored by vkrause).

REPOSITORY
  R280 Prison

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27909?vs=77158=77610

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

AFFECTED FILES
  autotests/aztec/encoding/aztec-complete-big.png
  autotests/aztec/encoding/aztec-complete-compact1.png
  autotests/aztec/encoding/aztec-complete-compact3.png
  autotests/aztec/encoding/aztec-complete-compact4.png
  autotests/aztec/encoding/aztec-complete-full5.png
  autotests/aztecbarcodetest.cpp
  autotests/code128barcodetest.cpp
  src/lib/abstractbarcode.cpp
  src/lib/abstractbarcode.h
  src/lib/aztecbarcode.cpp
  src/lib/aztecbarcode.h
  src/lib/code128barcode.cpp
  src/lib/code39barcode.cpp
  src/lib/code93barcode.cpp
  src/lib/datamatrixbarcode.cpp
  src/lib/qrcodebarcode.cpp

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

D27730: Add API to check whether a barcode is one- or two-dimensional

[Volker Krause]

This revision was automatically updated to reflect the committed changes.
Closed by commit R280:3d4b8780a8d5: Add API to check whether a barcode is one- 
or two-dimensional (authored by vkrause).

REPOSITORY
  R280 Prison

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27730?vs=77607=77609

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

AFFECTED FILES
  CMakeLists.txt
  autotests/aztecbarcodetest.cpp
  autotests/code128barcodetest.cpp
  src/lib/CMakeLists.txt
  src/lib/abstractbarcode.cpp
  src/lib/abstractbarcode.h
  src/lib/aztecbarcode.cpp
  src/lib/code128barcode.cpp
  src/lib/code39barcode.cpp
  src/lib/code93barcode.cpp
  src/lib/datamatrixbarcode.cpp
  src/lib/qrcodebarcode.cpp
  src/quick/barcodequickitem.cpp
  src/quick/barcodequickitem.h
  tests/barcode.qml

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

D27730: Add API to check whether a barcode is one- or two-dimensional

[Volker Krause]

vkrause updated this revision to Diff 77607.
vkrause added a comment.


  Rebase and bump version number to 5.69.

REPOSITORY
  R280 Prison

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27730?vs=77128=77607

BRANCH
  arcpatch-D27730

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

AFFECTED FILES
  CMakeLists.txt
  autotests/aztecbarcodetest.cpp
  autotests/code128barcodetest.cpp
  src/lib/CMakeLists.txt
  src/lib/abstractbarcode.cpp
  src/lib/abstractbarcode.h
  src/lib/aztecbarcode.cpp
  src/lib/code128barcode.cpp
  src/lib/code39barcode.cpp
  src/lib/code93barcode.cpp
  src/lib/datamatrixbarcode.cpp
  src/lib/qrcodebarcode.cpp
  src/quick/barcodequickitem.cpp
  src/quick/barcodequickitem.h
  tests/barcode.qml

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

D28030: Also expose the true minimum size to QML

[Volker Krause]

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

REVISION SUMMARY
  Useful in case you want to implement manual scaling there, for example.

REPOSITORY
  R280 Prison

BRANCH
  pending

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

AFFECTED FILES
  src/quick/barcodequickitem.cpp
  src/quick/barcodequickitem.h
  tests/barcode.qml

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