[ANNOUNCE] GammaRay 3.0.0

[Allen Winter]

Announcing GammaRay 3.0.0
(not quite 2 years since the last release)

Highlights of this Release:
=
 * Port to Qt6.
 * Network operations now optionally allow capturing HTTP response body.
 * Objects can now be favorited via context menu. A favorited object appears in 
a separate item view above the main itemview
 * Add support for modifying QMargins in properties
 * Allow zooming with mouse wheel in Signals view
 * Filtering for an object now automatically expands the tree and selects the 
object
 * Fix a crash when an object is re-parented
 * Improved performance of signals view
 * Improved performance when target application triggers massive object 
destructions/constructions
 * Remove the KDAB commercial license.
 * Remove the 3D Widget Inspector View.
 * Remove the experimental VTK-based Object Visualizer.
 * Update 3rdparty/backward-cpp to version 1.6.
 * Update 3rdparty/lz4 to version 1.9.4.
 * Update 3rdparty/StackWalker.
 * Increase CMake requirement to version 3.16.0.

The source code can be found on GitHub at: https://github.com/KDAB/GammaRay
Tarballs and zipballs for v3.0.0 are available from: 
https://github.com/KDAB/GammaRay/releases

Since this release, we are no longer providing pre-built packages for some 
popular Linux distros
via the OpenSUSE Build Service, nor are we providing homebrew recipes for Mac 
users.
=>Build from source or ask your favorite distro/homebrew/chocolatey/etc to 
provide packages.

GammaRay is a tool to poke around in a Qt-application and also to manipulate
the application to some extent. GammaRay uses various DLL injection
techniques to hook into an application at runtime and provide access to a
lot of interesting information.

For more information about GammaRay, please see:
 * the KDAB GammaRay home page at http://www.kdab.com/gammaray
 * the GammaRay wiki at https://github.com/KDAB/GammaRay/wiki
 * the GammaRay User Manual at https://docs.kdab.com/gammaray-manual/latest/
 * the GammaRay API doc at https://docs.kdab.com/gammaray/latest/


-- 
Allen Winter | allen.win...@kdab.com | Senior Software Engineer & Teamlead
KDAB (USA) LLC, a KDAB Group company
Tel. USA +1-866-777-KDAB(5322) ext3
KDAB - The Qt, C++ and OpenGL Experts


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

Re: RFC: Erroring out if the platform you're building the Framework is not supported

[Allen Winter]

On Wednesday, February 16, 2022 9:42:18 AM EST Albert Astals Cid wrote:
> Supported == listed in metainfo.yaml
> 
> https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/245
> 
> What do you think?
> 
> I know parsing yaml like that isn't great but it seems to work for something 
> as simple as what I want there.
> 
> I guess it's probably a bit annoying for places like OpenBSD where having 
> Linux and FreeBSD supported probably means it would also work, but IMHO they 
> can either just use -DIGNORE_PLATFORM_CHECK=true or work with us so we get an 
> OpenBSD CI and then we add it to the metainfo.yaml list.
>
Here's why I asked Albert about this:
- for a long time kdesu builds fine on Mac
 - suddenly it doesn't build any longer
 - I spend time investigating and report a build failure
 - Developer (in this case Ahmad) spends time looking
- responds that the metainfo.yml says kdesu is only for Linux and FreeBSD
- Allen says "never mind then"
 - Today another person notices that kdesu no longer builds for Mac
   => repeat ad nauseam

So, to save everyone's time I propose that the CMakeLists.txt notifies 
the user explicitly if project is not supported on current platform.

Re: Fwd: KCalendarCore Require Libical 3.0

[Allen Winter]

Sorry. typo in the original message subject.
This is about "Libical" not "Libcal"

On Tuesday, November 24, 2020 8:13:12 AM EST Allen Winter wrote:
> I plan to implement this new requirement 2 weeks from now.
> unless there are good reasons against.
> 
> -Allen
> 
> --  Forwarded Message  --
> 
> Subject: KCalendarCore Require Libcal 3.0
> Date: Tuesday, November 17, 2020, 12:10:22 PM EST
> From: Allen Winter 
> To: KDE release coordination 
> 
> Release Team,
> 
> Unless there are objections, I'd like to require libical v3.0 in 
> kcalendarcore.
> libical v3.0.0 was released over 3 years ago (28 Oct 2017)
> 
> 
> 
> 
> 
> 
> -
> 
> 
> 

Fwd: KCalendarCore Require Libcal 3.0

[Allen Winter]

I plan to implement this new requirement 2 weeks from now.
unless there are good reasons against.

-Allen

--  Forwarded Message  --

Subject: KCalendarCore Require Libcal 3.0
Date: Tuesday, November 17, 2020, 12:10:22 PM EST
From: Allen Winter 
To: KDE release coordination 

Release Team,

Unless there are objections, I'd like to require libical v3.0 in kcalendarcore.
libical v3.0.0 was released over 3 years ago (28 Oct 2017)






-

Re: Gitlab Turn-off Issues

[Allen Winter]

On Sunday, June 28, 2020 12:27:41 PM EDT Allen Winter wrote:
> Can we remove the Issues feature on all invent projects?
> We're starting to see more and more people adding Issues.
> 
> For KOrganizer, bshah replaced Issues with Bugzilla.
> 
> I very much doubt we want or are ready to replace Bugzilla.
> 
Apologies, I had no idea this has been discussed many times previously.
I didn't intend to have a mean or angry tone.

What I really want to know is if we have some ideas or plans
to deal with people submitting issues to Issues instead of Bugzilla.
I'll follow this thread and see where it leads.

-Allen
 

Gitlab Turn-off Issues

[Allen Winter]

Can we remove the Issues feature on all invent projects?
We're starting to see more and more people adding Issues.

For KOrganizer, bshah replaced Issues with Bugzilla.

I very much doubt we want or are ready to replace Bugzilla.

Re: Who merges Merge Requests, and when?

[Allen Winter]

On Wednesday, June 10, 2020 12:19:36 PM EDT Glen Ditchfield wrote:
> In the Phabricator work flow, I would submit a patch, someone knowledgeable 
> would accept it, and I would `arc land` it.  Clear and simple.
> 
> GitLab doesn't have that "accept" step AFAIK.  The KDE Wiki's Infrastructure/
> GitLab page says "Once the Merge Request is accepted, KDE Developers will 
> merge it for you!"  That is imprecise;  I'm in the Developer group, but I'm 
> just a casual.
> 
> So, I have a couple of MRs in flight:
> 
> https://invent.kde.org/frameworks/kcalendarcore/-/merge_requests/1 hasn't 
> attracted any review comments.  I don't think I _should_ merge it, but I 
> think 
> I _can_, which makes me uneasy.
> 
> https://invent.kde.org/pim/kcalutils/-/merge_requests/5 had comments, which I 
> resolved.  So, do I merge it?  Do I wait for both reviewers to upvote it?  
> Does a reviewer merge it?
> 

Problem: There are not very many people interested in kcalendarcore or kcalutils
and even fewer that have the knowledge required to review your MRs.
I happen to be 1 of those people.  I will look at your MRs soon.

I am very happy to have another person interested in these libraries
and very much welcome your contributions.

In the case of kcalendarcore I had forgotten to setup notifications for that 
repo.
apologies

Typically, the maintainer(s) would merge.  Neither of these repos have a real 
maintainer, however.
I don't think we have any rules against self-merging though.

D29223: Update Taiwanese holidays

[Allen Winter]

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit R175:b1291acbfc09: Update Taiwanese holidays (authored by 
nhiga, committed by winterz).

REPOSITORY
  R175 KHolidays

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29223?vs=82085=82795

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

AFFECTED FILES
  holidays/holidays.qrc
  holidays/plan2/holiday_tw_zh
  holidays/plan2/holiday_tw_zh-tw

To: nhiga, winterz, cgiboudeaux, shrapnel
Cc: weisi, #kde_pim, kde-frameworks-devel, shrapnel, LeGast00n, cblack, 
fbampaloukas, michaelh, ngraham, bruns, dvasin, rodsevich, winterz, vkrause, 
mlaurent, knauss, dvratil

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

[Allen Winter]

This revision was automatically updated to reflect the committed changes.
Closed by commit R175:7f7533260efc: holidayregion.cpp - provide translatable 
strings for the German regions. (authored by winterz).

REPOSITORY
  R175 KHolidays

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29575?vs=82442=82525

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

AFFECTED FILES
  src/holidayregion.cpp

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

D29223: Update Taiwanese holidays

[Allen Winter]

winterz added a comment.


  all opposed to this patch please speak up soon

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

To: nhiga, winterz, cgiboudeaux, shrapnel
Cc: weisi, #kde_pim, kde-frameworks-devel, shrapnel, LeGast00n, cblack, 
fbampaloukas, michaelh, ngraham, bruns, dvasin, rodsevich, winterz, vkrause, 
mlaurent, knauss, dvratil

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

[Allen Winter]

winterz updated this revision to Diff 82442.
winterz added a comment.


  QLatin1-ify

REPOSITORY
  R175 KHolidays

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29575?vs=82398=82442

BRANCH
  master

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

AFFECTED FILES
  src/holidayregion.cpp

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

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

[Allen Winter]

winterz updated this revision to Diff 82398.
winterz added a comment.


  don't try to provide translatable string for unknown subdivisions

REPOSITORY
  R175 KHolidays

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29575?vs=82396=82398

BRANCH
  master

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

AFFECTED FILES
  src/holidayregion.cpp

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

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

[Allen Winter]

winterz added a comment.


  I'm guessing it's ok to depend on K5I18N ?

REPOSITORY
  R175 KHolidays

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

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

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

[Allen Winter]

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

REVISION SUMMARY
  The German holiday files now all have a proper country and name
  since commits 4bdc6f618e77348eeafa5e802154b95febc27eab 

  and 8b3f65ed1f40975aa559881fc3116029b7e7677e 

  
  this patch allows those names to be translated.
  
  also we can see the subdivision code in the regionName
  in the case we have a subdivision but no name.
  i.e say we have country "XX-YY" but name field is empty
  then we have regionName = countyCode(XX)(yy)

REPOSITORY
  R175 KHolidays

BRANCH
  master

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

AFFECTED FILES
  CMakeLists.txt
  src/CMakeLists.txt
  src/holidayregion.cpp

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

EBN Going Away

[Allen Winter]

In 2005 Adriaan and I setup a little service for improving code quality
which we named "The English Breakfast Network" (ebn.kde.org)

Sometime soon the server that runs the EBN will be taken down
and I have no intention of moving it elsewhere.  We could have
jenkins take over if someone wants to take that on.

api.kde.org will be retained

If you want to run krazy locally via command line see
https://community.kde.org/Guidelines_and_HOWTOs/Code_Checking

The documentation sanitizer also has a command line interface
if someone is interested in documenting how to get it and use it.

several Krazy checks can be done via Clazy these days, but not everything.
I plan to continue maintaining the Krazy tools as time permits.


-Allen

D29374: UK, Scotland: Fix syntax error by adding category of Early May Bank Holiday

[Allen Winter]

winterz added a comment.


  I committed this one for Weisi Dai

REPOSITORY
  R175 KHolidays

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

To: weisi, winterz, davidedmundson
Cc: jriddell, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29374: UK, Scotland: Fix syntax error by adding category of Early May Bank Holiday

[Allen Winter]

This revision was automatically updated to reflect the committed changes.
Closed by commit R175:682b18f75ca7: holidays/plan2/holiday_gb-sct_en-gb 
(authored by weisi, committed by winterz).

REPOSITORY
  R175 KHolidays

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29374?vs=81773=81953

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

AFFECTED FILES
  holidays/plan2/holiday_gb-sct_en-gb

To: weisi, winterz, davidedmundson
Cc: jriddell, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29374: UK, Scotland: Fix syntax error by adding category of Early May Bank Holiday

[Allen Winter]

winterz accepted this revision.
winterz added a comment.


  do you need me to commit this for you?
  
  my fault.  I should have run the test that looks for the syntax errors .. I 
don't recall doing that.

REPOSITORY
  R175 KHolidays

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

To: weisi, winterz, davidedmundson
Cc: jriddell, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

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

[Allen Winter]

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


  I don't know German and I don't know the Berlin holidays.
  but the tests pass and in general things look fine.

REPOSITORY
  R175 KHolidays

BRANCH
  master

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

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

Re: Information regarding upcoming Gitlab Migration

[Allen Winter]

On Sunday, April 26, 2020 9:40:01 PM EDT Bhushan Shah wrote:
> [Please keep sysad...@kde.org list or bs...@kde.org in the CC for
> replies]
> 
> Hello Community members,
> 
> In view of upcoming Gitlab migration, we sysadmin team wants to share
> the recommended structuring for the repositories on Gitlab.
> 
> We had multiple options,
> 
> - Flat structure: In this option we would have everything under one
>   single namespace/group: https://invent.kde.org/kde/knetwalk
> - Subgroups under top-level group: In this option we would have a groups
>   under KDE namespace: https://invent.kde.org/kde/games/knetwalk
> - Groups at top level: In this option we would establish a series of
>   groups at the top level, e.g.  https://invent.kde.org/games/knetwalk
> 
> We have discussed this with small but representative group of
> contributors or maintainers, and based on their suggestions, we
> recommend that we go with option 3. Having sub-groups at top level will
> allow us to,
> 
> - Provides good visibility on all reviews, tasks and other items within
>   the groups/modules we define
> - Provides improvements to discoverability of projects
> - Makes it possible for groups of projects to establish a group level
>   task board should it fit their needs (for tracking a release for
>   instance)
> - Makes the most semantic sense, as the ‘KDE’ top level group suggested
>   in option 2 is duplicative considering the Gitlab instance is under
>   kde.org.
> - The discoverability of projects is maximised, as there is no need to
>   open the top level ‘KDE’ group before going into the subgroup.
> 
> I've worked on draft "move" of the current set of the repositories in
> their respective subgroups at the repo-metadata project's branch [1].
> You can browse the directory structure to get idea of how final
> structure on Gitlab would look like.
> 
> If we don't have any objections we would like to implement this next
> week and move projects to https://invent.kde.org.
> 
> Thanks!
> Bhushan for sysadmin team
> 
> [1] 
> https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent
> 
... to answer your original question my opinion is +1

I do appreciate all the work the sysadmins are putting onto this endeavor and 
I'm glad
we are making the move. I hope it happens next week as planned.

-Allen

Re: Information regarding upcoming Gitlab Migration: clarifications

[Allen Winter]

On Thursday, April 30, 2020 5:15:43 PM EDT Albert Astals Cid wrote:
> El dijous, 30 d’abril de 2020, a les 21:31:02 CEST, Ben Cooksley va escriure:
> > On Fri, May 1, 2020 at 6:04 AM Ivan Čukić  wrote:
> > >
> > > > We have made a big fuss in the past about having different projects
> > > > that do the same thing and now we'll have that but also we'll have
> > > > several projects with the same name?
> > > > It really feels off to me and I wonder if this is related to the move to
> > > > gitlab.
> > >
> > > +1 to both sentiments - that projects should have different names and that
> > > this is a bit off topic for the gitlab migration.
> > 
> > The projects *DO* have very different names. That *HAS NOT* changed.
> > To use the example Bhushan gave above, one is called Plasma Mobile
> > Dialer and the other one is called Maui Dialer.
> > 
> > With the current git.kde.org setup, we have a flat namespace, so all
> > repositories if the name appears to be generic (as dialer is) have to
> > be namespaced by prefixing of the repository name.
> > 
> > With Gitlab however we will now namespaces that group repositories,
> > making the prefixing unnecessary and as some projects have complained
> > about, duplicative.
> > 
> > Otherwise you end up with plasma-mobile/plasma-mobile-dialer as your
> > path, which just looks silly.
> 
> Am I the only person that just has all the repos on the same folder? I 
> thought it was the common thing to do :?
> 
I use kdesrc-build and I see the repos in a hierarchy.
In particular, I like frameworks in frameworks in kdepim in kde/pim

I don't see that I'm setting any special "layout in a hierarchy" option in my 
kdesrc-buildrc

Re: Information regarding upcoming Gitlab Migration: clarifications

[Allen Winter]

On Thursday, April 30, 2020 5:15:43 PM EDT Albert Astals Cid wrote:
> El dijous, 30 d’abril de 2020, a les 21:31:02 CEST, Ben Cooksley va escriure:
> > On Fri, May 1, 2020 at 6:04 AM Ivan Čukić  wrote:
> > >
> > > > We have made a big fuss in the past about having different projects
> > > > that do the same thing and now we'll have that but also we'll have
> > > > several projects with the same name?
> > > > It really feels off to me and I wonder if this is related to the move to
> > > > gitlab.
> > >
> > > +1 to both sentiments - that projects should have different names and that
> > > this is a bit off topic for the gitlab migration.
> > 
> > The projects *DO* have very different names. That *HAS NOT* changed.
> > To use the example Bhushan gave above, one is called Plasma Mobile
> > Dialer and the other one is called Maui Dialer.
> > 
> > With the current git.kde.org setup, we have a flat namespace, so all
> > repositories if the name appears to be generic (as dialer is) have to
> > be namespaced by prefixing of the repository name.
> > 
> > With Gitlab however we will now namespaces that group repositories,
> > making the prefixing unnecessary and as some projects have complained
> > about, duplicative.
> > 
> > Otherwise you end up with plasma-mobile/plasma-mobile-dialer as your
> > path, which just looks silly.
> 
> Am I the only person that just has all the repos on the same folder? I 
> thought it was the common thing to do :?
> 
I use kdesrc-build and I see the repos in a hierarchy.
In particular, I like frameworks in frameworks in kdepim in kde/pim

I don't see that I'm setting any special "layout in a hierarchy" option in my 
kdesrc-buildrc

Re: Information regarding upcoming Gitlab Migration: clarifications

[Allen Winter]

On Thursday, April 30, 2020 5:15:43 PM EDT Albert Astals Cid wrote:
> El dijous, 30 d’abril de 2020, a les 21:31:02 CEST, Ben Cooksley va escriure:
> > On Fri, May 1, 2020 at 6:04 AM Ivan Čukić  wrote:
> > >
> > > > We have made a big fuss in the past about having different projects
> > > > that do the same thing and now we'll have that but also we'll have
> > > > several projects with the same name?
> > > > It really feels off to me and I wonder if this is related to the move to
> > > > gitlab.
> > >
> > > +1 to both sentiments - that projects should have different names and that
> > > this is a bit off topic for the gitlab migration.
> > 
> > The projects *DO* have very different names. That *HAS NOT* changed.
> > To use the example Bhushan gave above, one is called Plasma Mobile
> > Dialer and the other one is called Maui Dialer.
> > 
> > With the current git.kde.org setup, we have a flat namespace, so all
> > repositories if the name appears to be generic (as dialer is) have to
> > be namespaced by prefixing of the repository name.
> > 
> > With Gitlab however we will now namespaces that group repositories,
> > making the prefixing unnecessary and as some projects have complained
> > about, duplicative.
> > 
> > Otherwise you end up with plasma-mobile/plasma-mobile-dialer as your
> > path, which just looks silly.
> 
> Am I the only person that just has all the repos on the same folder? I 
> thought it was the common thing to do :?
> 
I use kdesrc-build and I see the repos in a hierarchy.
In particular, I like frameworks in frameworks in kdepim in kde/pim

I don't see that I'm setting any special "layout in a hierarchy" option in my 
kdesrc-buildrc

D28874: Taiwanese holidays

[Allen Winter]

winterz added a comment.


  In D28874#650661 , @ngraham wrote:
  
  > Do you not have commit access? I thought you were the maintainer based on 
the repo's history!
  
  
  Yes of course.
  I'm asking for assistance at this time.

REPOSITORY
  R175 KHolidays

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

To: shrapnel, #vdg, Zren, winterz
Cc: ngraham, winterz, kde-frameworks-devel, LeGast00n, cblack, michaelh, bruns

D28891: Nicaragua Holidays

[Allen Winter]

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


  other than the indentation in the .qrc file this is good to go.. tests pass
  
  would appreciate if someone would commit this for us.  (after fixing the 
indentation)

REPOSITORY
  R175 KHolidays

BRANCH
  master

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

To: carguello, winterz, #frameworks
Cc: ngraham, kde-frameworks-devel, #vdg, LeGast00n, cblack, michaelh, bruns

D28874: Taiwanese holidays

[Allen Winter]

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


  looks good.  all tests pass.
  
  could someone commit this for us?

REPOSITORY
  R175 KHolidays

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

To: shrapnel, #vdg, Zren, winterz
Cc: winterz, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D28874: Taiwanese holidays

[Allen Winter]

winterz added a comment.


  remove holidays/0001-added-holiday_tw_zh-and-updated-holiday.qrc.patch

REPOSITORY
  R175 KHolidays

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

To: shrapnel, #vdg, Zren, winterz
Cc: winterz, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D28891: Nicaragua Holidays

[Allen Winter]

winterz added inline comments.

INLINE COMMENTS

> holidays.qrc:101
>  plan2/holiday_mx_es
> -plan2/holiday_na_en-gb
> + plan2/holiday_na_en-gb
>  plan2/holiday_nc_fr

realign the indentation

> holidays.qrc:103
>  plan2/holiday_nc_fr
> + plan2/holiday_ni_es
>  plan2/holiday_nl_nl

realign the indentation

REPOSITORY
  R175 KHolidays

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

To: carguello, winterz, #frameworks
Cc: ngraham, kde-frameworks-devel, #vdg, LeGast00n, cblack, michaelh, bruns

D28874: Taiwanese holidays

[Allen Winter]

winterz added a comment.


  problems:
  
  - "religous" should be "religious"
  - missing ':' at the start of Constitution Day
- missing ':' at the start of Christmas Day

REPOSITORY
  R175 KHolidays

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

To: shrapnel, #vdg, Zren, winterz
Cc: winterz, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D28874: Taiwanese holidays

[Allen Winter]

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


  testing fails.  don't know why yet.

REPOSITORY
  R175 KHolidays

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

To: shrapnel, #vdg, Zren, winterz
Cc: winterz, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D28874: Taiwanese holidays

[Allen Winter]

winterz added a comment.


  you need to add the change to holidays.qrc to this patch

REPOSITORY
  R175 KHolidays

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

To: shrapnel, #vdg, Zren
Cc: winterz, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D28850: Updated Romanian holidays

[Allen Winter]

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


  looks fine.  I tested it.
  
  can someone commit this please?

REPOSITORY
  R175 KHolidays

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

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

D28834: Add metadata properties to calendar

[Allen Winter]

winterz added a comment.


  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

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

D28834: Add metadata properties to calendar

[Allen Winter]

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

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

D28834: Add metadata properties to calendar

[Allen Winter]

winterz added a comment.


  looks good.
  nice touch using Q_EMIT.

INLINE COMMENTS

> calendar_p.h:81
> +QString mIcon;
> +CalendarType mType;
>  };

CalendarType mType = ReadWrite ?

REPOSITORY
  R172 KCalendar Core

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

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

D27363: KHolidays: Convert license statements to SPDX expressions

[Allen Winter]

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

REPOSITORY
  R175 KHolidays

BRANCH
  spdx

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

To: cordlandwehr, winterz
Cc: cgiboudeaux, winterz, kde-frameworks-devel, LeGast00n, cblack, GB_2, 
michaelh, ngraham, bruns

Re: Banning QNetworkAccessManager

[Allen Winter]

On Wednesday, February 19, 2020 6:09:02 PM EST Albert Astals Cid wrote:
> El dimecres, 19 de febrer de 2020, a les 9:28:22 CET, Volker Krause va 
> escriure:
> > Additionally, improved documentation, a possible KNAM and/or driving the 
> > QNAM 
> > changes upstream can still be done alongside this obviously.
> 
> Also for Qt5 which will probably never be changed a clazy warning and making 
> it easy to run clazy on gitlab CI would be great.
> 

Krazy has a checker for QNetworkAccessManager use in Qt4 code.
I could add a checker for Qt5 code if someone tells me what to look for
(not that many people look at krazy reports. couldn't hurt. might help.

Re: Banning QNetworkAccessManager

[Allen Winter]

On Wednesday, February 19, 2020 6:09:02 PM EST Albert Astals Cid wrote:
> El dimecres, 19 de febrer de 2020, a les 9:28:22 CET, Volker Krause va 
> escriure:
> > Additionally, improved documentation, a possible KNAM and/or driving the 
> > QNAM 
> > changes upstream can still be done alongside this obviously.
> 
> Also for Qt5 which will probably never be changed a clazy warning and making 
> it easy to run clazy on gitlab CI would be great.
> 

Krazy has a checker for QNetworkAccessManager use in Qt4 code.
I could add a checker for Qt5 code if someone tells me what to look for
(not that many people look at krazy reports. couldn't hurt. might help.

Re: Banning QNetworkAccessManager

[Allen Winter]

On Wednesday, February 19, 2020 6:09:02 PM EST Albert Astals Cid wrote:
> El dimecres, 19 de febrer de 2020, a les 9:28:22 CET, Volker Krause va 
> escriure:
> > Additionally, improved documentation, a possible KNAM and/or driving the 
> > QNAM 
> > changes upstream can still be done alongside this obviously.
> 
> Also for Qt5 which will probably never be changed a clazy warning and making 
> it easy to run clazy on gitlab CI would be great.
> 

Krazy has a checker for QNetworkAccessManager use in Qt4 code.
I could add a checker for Qt5 code if someone tells me what to look for
(not that many people look at krazy reports. couldn't hurt. might help.

D27419: Update Japanese holidays

[Allen Winter]

This revision was automatically updated to reflect the committed changes.
Closed by commit R175:1f9332f8f322: Update Japanese holidays (authored by 
winterz).

REPOSITORY
  R175 KHolidays

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27419?vs=75732=75777

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

AFFECTED FILES
  holidays/plan2/holiday_jp_en-us
  holidays/plan2/holiday_jp_ja

To: nhiga, dvratil, winterz, cgiboudeaux
Cc: aacid, #kde_pim, kde-frameworks-devel, LeGast00n, cblack, fbampaloukas, 
GB_2, dcaliste, michaelh, ngraham, bruns, dvasin, rodsevich, winterz, vkrause, 
mlaurent, knauss, dvratil

D27419: Update Japanese holidays

[Allen Winter]

winterz accepted this revision.
winterz added a comment.


  I tested these changes locally.  works
  
  do you have commit access?

REPOSITORY
  R175 KHolidays

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

To: nhiga, dvratil, winterz, cgiboudeaux
Cc: #kde_pim, kde-frameworks-devel, LeGast00n, cblack, fbampaloukas, GB_2, 
dcaliste, michaelh, ngraham, bruns, dvasin, rodsevich, winterz, vkrause, 
mlaurent, knauss, dvratil

D27363: KHolidays: Convert license statements to SPDX expressions

[Allen Winter]

winterz added a comment.


  looks ok to me.

INLINE COMMENTS

> cgiboudeaux wrote in lunarphase.cpp:6
> This looks suspicious
> 
> @winterz ?

no, it's fine.

REPOSITORY
  R175 KHolidays

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

To: cordlandwehr
Cc: cgiboudeaux, winterz, kde-frameworks-devel, LeGast00n, cblack, GB_2, 
michaelh, ngraham, bruns

D26167: Update holidays and add flagdays and namedays for Sweden

[Allen Winter]

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


  looks fine.
  I also tested and the changes don't break anything.

REPOSITORY
  R175 KHolidays

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

To: riiga, #kde_pim, winterz
Cc: ltoscano, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

Check for Missing Tooltips and WhatsThis

[Allen Winter]

You might not know that Krazy can find widgets-n-stuff with missing tooltip, 
whatsthis, statustip or sethelptext

This is an optional Krazy check that you need to enable in your project .krazy 
file.
The "tipsandthis" check has been available since 2008 and haven't seen it used 
very much.
It might be crufty and need some updating.

Look at the KOrganizer report for example [1]

If you want to try it out, make sure you have a .krazy file at the top of your 
project tree.
In .krazy put the line "EXTRA tipsandthis"
Then wait a day and checkout the project's krazy report on the EBN.

Let me know about false positives or other problems.
Sorry to the translators .. if lots of new tooltips and whatsthis suddenly 
appear

-Allen (a big fan of tooltips)

[1] http://ebn.kde.org/krazy/reports/kde-4.x/pim/korganizer/index.html

D25753: EBN extra-cmake-modules transport cleanup

[Allen Winter]

winterz added a comment.


  please send me a list of urls that don't have https:  and I'll add them to 
the whitelist

REPOSITORY
  R240 Extra CMake Modules

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

To: jhayes, apol, cgiboudeaux
Cc: winterz, cgiboudeaux, kde-frameworks-devel, kde-buildsystem, LeGast00n, 
GB_2, bencreasy, michaelh, ngraham, bruns

Re: Blacklisting of PIM from the CI system

[Allen Winter]

On Tuesday, December 3, 2019 2:52:31 PM EST Volker Krause wrote:
> The complexity of the dependency graph is also a problem for onboarding new 
> people, and with kdelibs4support gone IMHO the largest technical dept here. 
> It's being worked on, albeit slowly, currently we are losing ~1 module per 
> release I think.
>
Silly questions

Why do we need 50-60 repos to build kontact?
why not 1 repo for kontact and all its stuff? (I miss kdepim)

do Krita or any of the other large applications have so many repositories 
devoted to them?

After all these years since the svn->git move I still understand why so many 
repostitories for Kontact.
For frameworks it makes sense, but I don't get it for applications

Re: Blacklisting of PIM from the CI system

[Allen Winter]

On Tuesday, December 3, 2019 2:52:31 PM EST Volker Krause wrote:
> The complexity of the dependency graph is also a problem for onboarding new 
> people, and with kdelibs4support gone IMHO the largest technical dept here. 
> It's being worked on, albeit slowly, currently we are losing ~1 module per 
> release I think.
>
Silly questions

Why do we need 50-60 repos to build kontact?
why not 1 repo for kontact and all its stuff? (I miss kdepim)

do Krita or any of the other large applications have so many repositories 
devoted to them?

After all these years since the svn->git move I still understand why so many 
repostitories for Kontact.
For frameworks it makes sense, but I don't get it for applications

D25106: Also allow invoking session restoration logic when apps are manually launched

[Allen Winter]

winterz added a comment.


  yay!

REPOSITORY
  R263 KXmlGui

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

To: ngraham, davidedmundson, #frameworks, dfaure, vkrause
Cc: winterz, lbeltrame, mlaurent, kde-frameworks-devel, LeGast00n, GB_2, 
michaelh, ngraham, bruns

D19996: WIP Add a global test for insecure http: URLs used in code or documentation

[Allen Winter]

winterz added a comment.


  FYI:  Today I added a Krazy checker to do this.  Should see results on the 
EBN in a day or 2.
  
  Although I am skipping the .htignore's, there will still be lots of false 
positives especially in the test programs.
  Let's see what happens.
  -Allen

REPOSITORY
  R240 Extra CMake Modules

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

To: vkrause
Cc: kossebau, winterz, knauss, cgiboudeaux, kde-frameworks-devel, 
kde-buildsystem, LeGast00n, GB_2, bencreasy, michaelh, ngraham, bruns

D24826: Enforce 100 chars line width

[Allen Winter]

winterz added a comment.


  I am a long-time advocate of columnLimits; however, in our modern world of 
programming I think 100 is too short.
  
  240 may be a bit too long: in my personal coding style scripts I try to limit 
to 120.   even 120 is hard to achieve sometimes.
  I feel that 240 is a fair compromise.
  
  -1 for this patch

REPOSITORY
  R240 Extra CMake Modules

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

To: romangg, #frameworks, cullmann
Cc: winterz, zzag, kde-frameworks-devel, kde-buildsystem, LeGast00n, GB_2, 
bencreasy, michaelh, ngraham, bruns

Re: Get Hot New Stuff Dead or Alive?

[Allen Winter]

On Sunday, October 13, 2019 1:57:06 PM EDT Ben Cooksley wrote:
> On Mon, Oct 14, 2019 at 6:06 AM Allen Winter  wrote:
> >
> > or maybe renamed?
> 
> Hi Allen,
> 
> >
> > How do I find out if there are any GHNS for KOrganizer.
> > The Import->GHNS menu in KOrganizer starts and I see the import dialog ok.
> > but that dialog is empty.
> >
> > I need to know if something is broken with the KOrganizer implementation
> > or if I should remove that feature.  Or maybe just nothing to import, which
> > makes me think I should remove the feature.
> >
> >
> 
> As a first starting point, i'd suggest asking what endpoint your
> implementation is reaching out to.
> Depending on when it was last updated, there are at least 3 different
> places KOrganizer could be trying to fetch from.
> 
> Two of them are essentially static, unchangeable archives for legacy
> implementations now, while the other one is store.kde.org.

For KOrganizer, NewStuff is both dead and alive :)

there are some importable calendars .. but they are ancient.
anyway, I have a phab patch that Laurent is helping me fix properly.

thanks for the help Ben

Get Hot New Stuff Dead or Alive?

[Allen Winter]

or maybe renamed?

How do I find out if there are any GHNS for KOrganizer.
The Import->GHNS menu in KOrganizer starts and I see the import dialog ok.
but that dialog is empty.

I need to know if something is broken with the KOrganizer implementation
or if I should remove that feature.  Or maybe just nothing to import, which
makes me think I should remove the feature.

D23930: Set XCB to required if building the X backend

[Allen Winter]

winterz added a comment.


  +1
  will fix the problem I reported.

REPOSITORY
  R278 KWindowSystem

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

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

Re: KCalendarCore plugins/datasources?

[Allen Winter]

On Monday, August 12, 2019 6:49:48 AM EDT Daniel Vrátil wrote:
> On Sunday, 11 August 2019 12:12:10 CEST Bhushan Shah wrote:
> > [I am not subscribed to kde-pim list, please keep me or k-f-d in CC]
> > 
> > Hello,
> 
> Hi Bhushan,
> 
> > 
> > So yesterday I was discussing this with the Volker in #kde-devel, that
> > currently kcalcore doesn't provide a "plugin interface" to create a
> > various data sources like, file storage, online/cloud storage, or
> > akonadi storage, and Akonadi have it's own custom code for this.
> > Would it make sense to have something like this in kcalcore itself?
> > Volker mentioned to me that it needs close look at Akonadi based
> > implementation and trying to finalize API.
> 
> There's KCalendarCore::CalStorage which allows users to write their own 
> calendar data sources, which could be used as a plugin interface. Extending 
> the library with a plugin infrastructure would also be OK IMO, but if we want 
> to have a bunch of plugins to integrate between KCalendarCore and various 
> backend-specific libraries (e.g. KGAPI, KDAV, Kolab, ...), we should create 
> KCalendarAddons (or something like that), assuming there's actually any 
> demand 
> for this.
> 
> For Akonadi the way it works is that we create an instance of 
> KCalendarCore::Calendar and directly populate it with entities loaded from 
> Akonadi. We don't use the CalStorage interface for that as we don't need that 
> kind of abstraction to integrate between KCalendarCore and Akonadi.
> 
Agree with Dan.
I'd say not to put plugins directly into KCalendarCore, but create a new repo 
for that purpose.
If needed.

Re: New framework: KCalCore

[Allen Winter]

On Thursday, July 18, 2019 12:18:36 PM EDT Volker Krause wrote:
> On Wednesday, 17 July 2019 01:51:42 CEST Aleix Pol wrote:
> > On Tue, Jul 16, 2019 at 6:10 PM Volker Krause  wrote:
> > > On Monday, 15 July 2019 18:43:42 CEST Aleix Pol wrote:
> > > > On Fri, Jul 12, 2019 at 9:03 PM Allen Winter  wrote:
> > > > > On Friday, July 12, 2019 12:23:58 PM EDT Volker Krause wrote:
> > > > > > With the 19.08 release approaching (and thus the deadline for
> > > > > > incompatible
> > > > > > changes if we go ahead with this plan), I'd like to raise this again
> > > > > > for
> > > > > > getting to a decision :)
> > > > > > 
> > > > > > Summary of what happened in the past weeks:
> > > > > > - the Person/Attendee slicing issue was fixed by making both
> > > > > > independent
> > > > > > types - several "leaf" types were turned into implicitly shared
> > > > > > value
> > > > > > types rather than being used heap-allocated inside shared pointers
> > > > > > - the dependency on the Akonadi supertrait.h header file was removed
> > > > > > - the virtual_hook usage in the incidence de/serialization code was
> > > > > > replaced by new virtual methods
> > > > > > 
> > > > > > Unless I missed something, the remaining unaddressed feedback is
> > > > > > down
> > > > > > to:
> > > > > > - Rename KCalCore to something else. I'm ok with executing the
> > > > > > rename,
> > > > > > but
> > > > > > somebody needs to tell me the new name :)
> > > > > 
> > > > > I don't remember the reason for changing the name.
> > > > > I vote for not changing the name. KCalCore is as good as any, imo
> > > > > 
> > > > > > - Alexander P's fundamental objections to the current KCalCore API
> > > > > > 
> > > > > > How do we proceed?
> > > > > > 
> > > > > > Thanks,
> > > > > > Volker
> > > > > > 
> > > > > > On Sunday, 7 April 2019 14:45:09 CEST Volker Krause wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > I'd like to propose KCalCore for review to move from KDE PIM to
> > > > > > > KF5.
> > > > > > > 
> > > > > > > KCalCore is an implementation of the iCalendar standard based on
> > > > > > > libical,
> > > > > > > covering the data model, input/output and the rather complex
> > > > > > > recurrence
> > > > > > > algorithms defined in that standard. It's used outside of KDE PIM
> > > > > > > as
> > > > > > > well,
> > > > > > > e.g. by Zanshin or the Plasma Mobile calendar app.
> > > > > > > 
> > > > > > > KCalCore depends on Qt and libical only, making it a Tier 1
> > > > > > > functional
> > > > > > > framework.
> > > > > > > 
> > > > > > > KCalCore used to be part of part of kdepimlibs in the KDE4 era, so
> > > > > > > it's well prepared for complying with the API and ABI guarantees.
> > > > > > > 
> > > > > > > I'd suggest the same timeline as proposed for KContacts [1].
> > > > > > > During
> > > > > > > the PIM
> > > > > > > sprint we did a number of fixes and cleanups as part of the review
> > > > > > > for
> > > > > > > KF5
> > > > > > > that make 19.08 the earliest release after which we can switch as
> > > > > > > well, so
> > > > > > > we are looking at a switch in Sep/Oct this year.
> > > > 
> > > > If you don't remember, just scroll up a bit. :P
> > > > 
> > > > I went through the thread and that's what we said:
> > > > - It's a framework to understand the ical format, this is not conveyed
> > > > by the current name
> > > > - The Core postfix doesn't add anything and we are already using it
> > > > for differentiating different framework targets (e.g. KF5::ConfigCore
> > > > and KF5::ConfigGui)
> > > 
> > > "Core&quo

Re: New framework: KCalCore

[Allen Winter]

On Friday, July 12, 2019 12:23:58 PM EDT Volker Krause wrote:
> With the 19.08 release approaching (and thus the deadline for incompatible 
> changes if we go ahead with this plan), I'd like to raise this again for 
> getting to a decision :)
> 
> Summary of what happened in the past weeks:
> - the Person/Attendee slicing issue was fixed by making both independent types
> - several "leaf" types were turned into implicitly shared value types rather 
> than being used heap-allocated inside shared pointers
> - the dependency on the Akonadi supertrait.h header file was removed
> - the virtual_hook usage in the incidence de/serialization code was replaced 
> by new virtual methods
> 
> Unless I missed something, the remaining unaddressed feedback is down to:
> - Rename KCalCore to something else. I'm ok with executing the rename, but 
> somebody needs to tell me the new name :)

I don't remember the reason for changing the name.
I vote for not changing the name. KCalCore is as good as any, imo

> - Alexander P's fundamental objections to the current KCalCore API
> 
> How do we proceed?
> 
> Thanks,
> Volker
> 
> On Sunday, 7 April 2019 14:45:09 CEST Volker Krause wrote:
> > Hi,
> > 
> > I'd like to propose KCalCore for review to move from KDE PIM to KF5.
> > 
> > KCalCore is an implementation of the iCalendar standard based on libical,
> > covering the data model, input/output and the rather complex recurrence
> > algorithms defined in that standard. It's used outside of KDE PIM as well,
> > e.g. by Zanshin or the Plasma Mobile calendar app.
> > 
> > KCalCore depends on Qt and libical only, making it a Tier 1 functional
> > framework.
> > 
> > KCalCore used to be part of part of kdepimlibs in the KDE4 era, so it's well
> > prepared for complying with the API and ABI guarantees.
> > 
> > I'd suggest the same timeline as proposed for KContacts [1]. During the PIM
> > sprint we did a number of fixes and cleanups as part of the review for KF5
> > that make 19.08 the earliest release after which we can switch as well, so
> > we are looking at a switch in Sep/Oct this year.
> > 
> > 
> > Thanks,
> > Volker
> > 
> > [1]
> > https://mail.kde.org/pipermail/kde-frameworks-devel/2019-April/084057.html
> 
> 

[ANNOUNCE] GammaRay 2.11.0

[Allen Winter]

Announcing GammaRay 2.11.0

Highlights of this Release:
=
 * Drop support for Qt 4 and Qt <= 5.4.
 * Drop support for MSVC 2010 and MSVC 2012, as well as GCC < 4.8.
 * Add support for more QtNetwork properties.
 * Add new network operations monitoring tool.
 * Fix inspection of QJson types.
 * Add thread affinity check to the problem reporter.
 * Add new event monitoring tool.
 * Initial forward compatibility with Qt6 build system.
 * Improved performance of the Qt Quick 2 inspector and the signal monitor.

The source code can be found on GitHub at: https://github.com/KDAB/GammaRay
Tarballs and zipballs for v2.11.0 are available from: 
https://github.com/KDAB/GammaRay/releases

For Linux users:
 * we provide pre-built packages for some popular distributions at:
https://software.opensuse.org/package/gammaray

For OSX users:
 * we provide a homebrew recipe, see:
https://github.com/KDAB/homebrew-tap

For Windows users:
 * you'll need to build from source

GammaRay is a tool to poke around in a Qt-application and also to manipulate 
the application to some extent. GammaRay uses various DLL injection
techniques to hook into an application at runtime and provide access to a
lot of interesting information.

For more information about GammaRay, please see:
 * the KDAB GammaRay home page at http://www.kdab.com/gammaray
 * the GammaRay wiki at https://github.com/KDAB/GammaRay/wiki
 * the GammaRay User Manual at https://docs.kdab.com/gammaray-manual/latest/
 * the GammaRay API doc at https://docs.kdab.com/gammaray/latest/

-- 
Allen Winter | allen.win...@kdab.com | Senior Software Engineer
KDAB (USA) LLC, a KDAB Group company
Tel. USA +1-866-777-KDAB(5322) ext3
KDAB - The Qt, C++ and OpenGL Experts


smime.p7s
Description: S/MIME cryptographic signature

Re: New framework: KCalCore

[Allen Winter]

Clazy is complaining about missing assign operators.  Do we care?
If so, I can take a look at adding them or if anyone else wants to do that.
-Allen

./src/calendar.cpp
line 305: for (it = vals.constBegin(); it != vals.constEnd(); ++it) {
=> Using assign operator but class 
QTypedArrayData >::const_iterator has 
copy-ctor but no assign operator

./src/calfilter.cpp
line 161: for (it = attendees.begin(); it != attendees.end(); ++it) {
=> Using assign operator but class 
QTypedArrayData >::const_iterator has 
copy-ctor but no assign operator

./src/freebusy.cpp
line 120: for (it = eventList.constBegin(); it != eventList.constEnd(); 
++it) {
=> Using assign operator but class 
QTypedArrayData >::const_iterator has copy-ctor 
but no assign operator
line 299: for (it = periods.constBegin(); it != periods.constEnd(); ++it) {
=> Using assign operator but class 
QTypedArrayData::const_iterator has copy-ctor but no assign 
operator

./src/icalformat_p.cpp
line 628: for (atIt = attachments.constBegin(); atIt != 
attachments.constEnd(); ++atIt) {
=> Using assign operator but class 
QTypedArrayData >::const_iterator has 
copy-ctor but no assign operator

./src/icaltimezones.cpp
line 493: begin = phase.transitions.cbegin();
=> Using assign operator but class 
QTypedArrayData::const_iterator has copy-ctor but no assign operator

./src/incidencebase.cpp
line 513: for (it = d->mAttendees.constBegin(); it != 
d->mAttendees.constEnd(); ++it) {
=> Using assign operator but class 
QTypedArrayData >::const_iterator has 
copy-ctor but no assign operator
line 530: for (itA = d->mAttendees.constBegin(); itA != 
d->mAttendees.constEnd(); ++itA) {
=> Using assign operator but class 
QTypedArrayData >::const_iterator has 
copy-ctor but no assign operator
line 544: for (it = d->mAttendees.constBegin(); it != 
d->mAttendees.constEnd(); ++it) {
=> Using assign operator but class 
QTypedArrayData >::const_iterator has 
copy-ctor but no assign operator

./src/vcalformat.cpp
line 1603: for (eIt = d->mEventsRelate.constBegin(); eIt != 
d->mEventsRelate.constEnd(); ++eIt) {
=> Using assign operator but class 
QTypedArrayData >::const_iterator has copy-ctor 
but no assign operator
line 1607: for (tIt = d->mTodosRelate.constBegin(); tIt != 
d->mTodosRelate.constEnd(); ++tIt) {
=> Using assign operator but class 
QTypedArrayData >::const_iterator has copy-ctor 
but no assign operator


 Sunday, April 7, 2019 8:45:09 AM EDT Volker Krause wrote:
> Hi,
> 
> I'd like to propose KCalCore for review to move from KDE PIM to KF5.
> 
> KCalCore is an implementation of the iCalendar standard based on libical, 
> covering the data model, input/output and the rather complex recurrence 
> algorithms defined in that standard. It's used outside of KDE PIM as well, 
> e.g. by Zanshin or the Plasma Mobile calendar app.
> 
> KCalCore depends on Qt and libical only, making it a Tier 1 functional 
> framework.
> 
> KCalCore used to be part of part of kdepimlibs in the KDE4 era, so it's well 
> prepared for complying with the API and ABI guarantees.
> 
> I'd suggest the same timeline as proposed for KContacts [1]. During the PIM 
> sprint we did a number of fixes and cleanups as part of the review for KF5 
> that make 19.08 the earliest release after which we can switch as well, so we 
> are looking at a switch in Sep/Oct this year.
> 
> 
> Thanks,
> Volker
> 
> [1] https://mail.kde.org/pipermail/kde-frameworks-devel/2019-April/084057.html

Re: New framework: KCalCore

[Allen Winter]

On Sunday, April 14, 2019 7:31:41 AM EDT David Faure wrote:
> On dimanche 7 avril 2019 14:45:09 CEST Volker Krause wrote:
> > Hi,
> > 
> > I'd like to propose KCalCore for review to move from KDE PIM to KF5.
> > 
> > KCalCore is an implementation of the iCalendar standard based on libical,
> 
> I wonder about the name, which doesn't mean much outside the circle of PIM 
> people. Shouldn't this be called KCalendar ?
> 
> If the "Core" simply means non-GUI, we certainly don't have that word in 
> every non-GUI framework.
> 
> > covering the data model, input/output and the rather complex recurrence
> > algorithms defined in that standard. It's used outside of KDE PIM as well,
> > e.g. by Zanshin or the Plasma Mobile calendar app.
> 
> This makes me wonder: where does that mobile calendar app get the events from?
> Akonadi? (then it still depends on kde/pim/*, and this move in itself doesn't 
> really remove the unwanted workspace->apps dependency?)
> 
> Zanshin does use akonadi (though one could imagine a mobile version that only 
> uses KDav and KCalCore^H^H^H KCalendar).
> 
> 
> Some review:
> 
> icalformat_p.h://TODO: KDE5, move this implementation to icalformat_p.cpp
> incidencebase.h: * // TODO_KDE5: Provide a virtual serialize() method, as 
> done with assign() and equals().
> incidencebase.h: * // TODO_KDE5: Provide a virtual serialize() method, as 
> done with assign() and equals().
> person.h:// TODO_KDE5: FIXME: This operator does slicing,if the object is 
> in fact one of the derived classes (Attendee)
> 
> This would be the perfect time to make these changes, if they are valid.
> 
> Allen, the first TODO above is from you (commit efe923294b4d7).
> I don't get it, this is a _p.h file (i.e. no SC/BC guarantees), why not just 
> outline the method if you wanted to?
> 
I'll remove that TODO in icalformat_p.h
No idea why... from 2013.  


> The "TODO: KDE5:" in calendar.h however looks like pie-in-the-sky wishful 
> thinking, but maybe the suggestion
> about merging some virtual methods makes sense, I don't know.
> 
> 

D19092: Add bison minimum version of 2.4.1 due to %code

[Allen Winter]

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


  I'm for this.
  I never created such a patch because I wasn't sure what minimum version was 
needed.
  
  On Mac, what I do is install the homebrew bison and export 
PATH=/usr/local/opt/bison/bin:$PATH
  
  I'd even be in favor of setting the minimum version to 3.0

REPOSITORY
  R309 KService

BRANCH
  bison_min_version (branched from master)

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

To: hindenburg, #frameworks, winterz
Cc: winterz, kde-frameworks-devel, michaelh, ngraham, bruns

EBN Still Needed?

[Allen Winter]

I was notified today that the Krazy runs on the EBN have been stuck (due to a 
stale lockfile)
for over 3 months.   Is this an indication that nobody looks at the EBN reports 
any longer?

I still maintain Krazy and am happy to make modifications, but I don't see the 
point
unless someone actually reads and acts on the reports.

Note that clazy does replace Krazy on most everything (C++) so it could
very well be that people are relying on Clazy instead of Krazy.

This is not about the API dox generation side of things, which of course we 
keep.

But has the EBN code and documentation checking service out lived its 
usefulness?
Shut it down?

D19996: WIP Add a global test for insecure http: URLs used in code or documentation

[Allen Winter]

winterz added a comment.


  this would be a nice addition to Krazy.  on my todo list.

REPOSITORY
  R240 Extra CMake Modules

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

To: vkrause
Cc: winterz, knauss, cgiboudeaux, kde-frameworks-devel, kde-buildsystem, 
michaelh, ngraham, bruns

[EBN] Re: Fwd: Cron /home/api/bin/update-all

[Allen Winter]

This is about investigating brokenness with the API generation on the EBN 
machine.
If you know anything about it please contact me so we can fix properly.
-Allen

On Thursday, December 27, 2018 8:13:04 AM EST Allen Winter wrote:
> Do either of you know why parsedoxlog.sh was removed?
> And what to do about it?
> we can easily restore parsedoxlog.sh if it was removed by mistake
> -Allen

I found out the following:

   someone modified /srv/sources/websites/quality-kde-org/tools/parse-api-logs 
on 12 Dec
   that someone removed the '$' from line6 of parse-api-logs 
   i.e.
 -$BINPATH/parsedoxlog.sh --version kde-"$BRANCH"
 +BINPATH/parsedoxlog.sh --version kde-"$BRANCH"

they also changed /srv/sources/websites/quality-kde-org/tools/update-mapper
+components=
 
   they left these changes uncommited .. /srv/sources/websites/quality-kde-org 
is a git repo

 As I am unaware who or why this was done I am reverting these changes.

> 
> --  Forwarded Message  --
> 
> Subject: Cron  /home/api/bin/update-all
> Date: Wednesday, December 26, 2018, 5:05:01 PM EST
> From: (Cron Daemon) 
> To: win...@kde.org
> 
> update-all run by api
> Wed Dec 26 22:05:01  2018: 59748 
> Wed Dec 26 22:05:01  2018: *** Update script checkouts
> Wed Dec 26 22:05:13  2018: *** Update checkouts
> Wed Dec 26 22:10:26  2018: *** Performing quality checks
> tar: .: file changed as we read it
> Wed Dec 26 23:49:27  2018: *** Setting up symlinks
> Wed Dec 26 23:49:27  2018: *** Start QCH and ManPage generation
> Thu Dec 27 00:15:47  2018: *** Update Classmapper files
> Thu Dec 27 00:16:15  2018: *** Update CMake modules doc
> Thu Dec 27 00:16:15  2018: *** Update User Manuals
> Thu Dec 27 00:16:15  2018: *** Update User Mkdocs Manuals
> Thu Dec 27 00:16:16  2018: *** Update details on EBN for API Generation
> /home/api/bin/parse-api-logs: line 6: BINPATH/parsedoxlog.sh: No such file or 
> directory
> Thu Dec 27 00:16:22  2018: *** Clean the db
> Thu Dec 27 00:16:22  2018: * DONE *
> 
> -

D16300: Remove double underscore (__) from header include guards

[Allen Winter]

winterz added a comment.


  fyi, krazy in strict mode will check for leading and trailing underscores on 
the include guards.
  I don't run krazy in strict mode on the EBN, however.
  
  I could make this a standard check if we want so the EBN would pick it up too.

REPOSITORY
  R39 KTextEditor

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

To: kossebau, #kate, cullmann
Cc: winterz, bcooksley, broulik, cullmann, kwrite-devel, kde-frameworks-devel, 
michaelh, ngraham, bruns, demsking, sars, dhaumann

D14524: Fix compiler warning -Wimplicit-fallthrough

[Allen Winter]

winterz added a comment.


  agree that Q_FALLTHROUGH(); is a better idea.
  it doesn't duplicate code and it informs the reader that the fallthrough is 
intentional

REPOSITORY
  R216 Syntax Highlighting

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

To: dhaumann, vkrause
Cc: winterz, aacid, kwrite-devel, kde-frameworks-devel, michaelh, kevinapavew, 
ngraham, bruns, demsking, cullmann, sars, dhaumann

D14154: Add

[Allen Winter]

This revision was not accepted when it landed; it landed in state "Needs 
Revision".
This revision was automatically updated to reflect the committed changes.
Closed by commit R175:8c49f9b3dfe2: more Japanese holiday updates from phanect 
(authored by winterz).

REPOSITORY
  R175 PIM: KHolidays

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D14154?vs=37860=38177

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

AFFECTED FILES
  holidays/plan2/holiday_jp_en-us
  holidays/plan2/holiday_jp_ja

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

D13828: Revert "updated Japanese holidays (in Japanese and English)"

[Allen Winter]

winterz added a comment.


  please close this

REPOSITORY
  R175 PIM: KHolidays

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

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

D13812: Revert "updated Japanese holidays (in Japanese and English)"

[Allen Winter]

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit R175:1c2ecfbf9570: holiday_jp_ja, holiday_jp-en_us -  updated 
Thanks for the patch phanect (authored by winterz).

REPOSITORY
  R175 PIM: KHolidays

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13812?vs=36951=37342

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

AFFECTED FILES
  holidays/plan2/holiday_jp_en-us
  holidays/plan2/holiday_jp_ja

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

D7415: kconfig: kcfg.xsd do not require a kcfgfile

[Allen Winter]

This revision was automatically updated to reflect the committed changes.
Closed by commit R237:dba6d83ee412: kcfg.xsd - do not require a kcfgfile 
element (authored by winterz).

REPOSITORY
  R237 KConfig

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D7415?vs=18394=33780

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

AFFECTED FILES
  src/kconfig_compiler/kcfg.xsd

To: winterz, dfaure
Cc: dfaure, #frameworks, michaelh, ngraham, bruns

D7415: kconfig: kcfg.xsd do not require a kcfgfile

[Allen Winter]

winterz added a comment.


  ping.
  this is still relevant.
  some kconfigxt files don't set the kcfgfile element.
  
  to name a few:
  mailcommon/src/settings/mailcommon.kcfg
  kdepim-runtime/agents/newmailnotifier/newmailnotifieragentsettings.kcfg
  pim-data-exporter/gui/settings/pimsettingexporterglobalconfig.kcfg
  grantlee-editor/grantleethemeeditor/settings/grantleethemeeditor.kcfg
  libksieve/src/ksieveui/settings/sieve-editor.kcfg.cmake
  knotes/src/settings/knotesglobalconfig.kcfg.cmake
  messagelib/messagelist/src/core/settings.kcfg
  
messagelib/messageviewer/src/messageviewerheaderplugins/defaultgrantleeheaderstyleplugin/settings/defaultgrantleeheaderstyleplugin.kcfg
  libgravatar/src/settings/gravatar.kcfg
  pim-sieve-editor/src/settings/sieveeditorglobalconfig.kcfg
  kmail/agents/archivemailagent/settings/archivemailagentsettings.kcfg

REPOSITORY
  R237 KConfig

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

To: winterz
Cc: #frameworks, michaelh, bruns

Re: Changes to networkmanager-qt - breakage in plasma-workspace

[Allen Winter]

krop already fixed that

On Thursday, March 29, 2018 6:21:41 PM EDT Ben Cooksley wrote:
> Hi Jan,
> 
> It seems that as part of your recent changes to networkmanager-qt to
> increase the dependency to 1.0.0 you've made some other changes which
> mean the appropriate include paths are no longer being provided to
> projects that depend on networkmanager-qt.
> 
> This has the unfortunate effect that plasma-workspace is no longer
> able to build on the CI system.
> 
> The error is:
> 
> In file included from /usr/include/libnm/nm-object.h:29:0,
>  from /usr/include/libnm/nm-access-point.h:29,
>  from /usr/include/libnm/NetworkManager.h:26,
>  from
> /home/jenkins/install-prefix/include/KF5/NetworkManagerQt/networkmanagerqt/ipconfig.h:31,
>  from
> /home/jenkins/install-prefix/include/KF5/NetworkManagerQt/networkmanagerqt/device.h:33,
>  from
> /home/jenkins/install-prefix/include/KF5/NetworkManagerQt/networkmanagerqt/manager.h:31,
>  from
> /home/jenkins/install-prefix/include/KF5/NetworkManagerQt/NetworkManagerQt/Manager:1,
>  from /home/jenkins/workspace/Dependency Build Plasma
> kf5-qt5 SUSEQt5.9/plasma-workspace/dataengines/geolocation/geolocation.cpp:25:
> /usr/include/libnm/nm-types.h:24:10: fatal error: gio/gio.h: No such
> file or directory
> 
> Could you please take a look?
> 
> Thanks,
> Ben
> 

Re: KHolidays as Framework (redux)

[Allen Winter]

I'm wrong. the changes are BC since I'm just moving static functions around.
Moving KHolidays anytime you want is fine with me.

On Sunday, January 14, 2018 2:02:48 PM EST Volker Krause wrote:
> On Sunday, 14 January 2018 16:50:08 CET Sandro Knauß wrote:
> > @Volker:  Is there a need to rush releasing KHolidays it under frameworks?
> 
> this request is pending since more than 24 month, not exactly my definition 
> of 
> rushing things ;-)
> 
> We should do the move reasonably early before the next application release 
> IMHO, so we don't collide with the pre-releases there. Apart from that I 
> don't 
> see any particular timing constraints.
> 
> > As far I see it, the include mechanism do not change find_package do not
> > need to change and also the target_libraries do not need to changed also
> > the API is fixed so far -> no changes in kdepim needed.
> 
> Exactly, it's all ready to go since two years.
> 
> > The only thing that
> > changes is the big bump of the version number and there will be some BIC
> > cleanup, so there will be BIC breakage with that move. Distributions need
> > to rebuild everything against the new framework. With only BIC changes
> > there should be no big issue for distributions to ship a uptodate kdepim
> > (17.12.X) with a uptodate KDE frameworks.
> 
> Which BIC changes do you have in mind? The ABI has been stable since August 
> 2015 from what I can see.
> 
> Regards,
> Volker
> 
> > PS: please also inform distributi...@kde.org, if the switch has a fixed
> > date.
> > On Sonntag, 14. Januar 2018 15:59:46 CET Allen Winter wrote:
> > > I don't object to making KHolidays a framework.
> > > I kinda object to the short timeline.
> > > 
> > > I wanted to finish up some BIC cleaning.  No API changes planned at this
> > > time. I'll try to hurry.
> > > 
> > > On Sunday, January 14, 2018 4:20:38 AM EST Volker Krause wrote:
> > > > On Tuesday, 6 September 2016 12:03:15 CET Volker Krause wrote:
> > > > > On Friday 01 January 2016 18:24:17 David Faure wrote:
> > > > > > On Thursday 24 December 2015 12:28:13 John Layt wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > It's xmas holidays, so it must be time to poke a stick at
> > > > > > > KHolidays
> > > > > > > again
> > > > > > > for inclusion as a Framework. As far as I am aware there are no
> > > > > > > outstanding
> > > > > > > porting issues with KHolidays and it is ready for review to be
> > > > > > > included
> > > > > > > as
> > > > > > > a Tier 1 Framework in the next possible release. What's the next
> > > > > > > step?
> > > > > > 
> > > > > > Please make sure it passes all of the items in this checklist
> > > > > > https://community.kde.org/Frameworks/CreationGuidelines
> > > > > 
> > > > > AFAICS this is followed, apart from using the KF5 version number and
> > > > > actually being marked as a framework, which I guess is pending
> > > > > framework
> > > > > approval.
> > > > 
> > > > This got lost somehow, any objection to executing the move to frameworks
> > > > for 5.43, say end of this week?
> > > > 
> > > > Regards,
> > > > Volker


-- 
Allen Winter | allen.win...@kdab.com | Senior Software Engineer
KDAB (USA) LLC, a KDAB Group company
Tel. USA +1-866-777-KDAB(5322) ext3
KDAB - The Qt, C++ and OpenGL Experts


smime.p7s
Description: S/MIME cryptographic signature

Re: KHolidays as Framework (redux)

[Allen Winter]

I don't object to making KHolidays a framework.
I kinda object to the short timeline.

I wanted to finish up some BIC cleaning.  No API changes planned at this time.
I'll try to hurry.



On Sunday, January 14, 2018 4:20:38 AM EST Volker Krause wrote:
> On Tuesday, 6 September 2016 12:03:15 CET Volker Krause wrote:
> > On Friday 01 January 2016 18:24:17 David Faure wrote:
> > > On Thursday 24 December 2015 12:28:13 John Layt wrote:
> > > > Hi,
> > > > 
> > > > It's xmas holidays, so it must be time to poke a stick at KHolidays
> > > > again
> > > > for inclusion as a Framework. As far as I am aware there are no
> > > > outstanding
> > > > porting issues with KHolidays and it is ready for review to be included
> > > > as
> > > > a Tier 1 Framework in the next possible release. What's the next step?
> > > 
> > > Please make sure it passes all of the items in this checklist
> > > https://community.kde.org/Frameworks/CreationGuidelines
> > 
> > AFAICS this is followed, apart from using the KF5 version number and
> > actually being marked as a framework, which I guess is pending framework
> > approval.
> 
> This got lost somehow, any objection to executing the move to frameworks for 
> 5.43, say end of this week?
> 
> Regards,
> Volker

Re: Krazy source code

[Allen Winter]

On Sunday, November 12, 2017 1:02:42 PM EST Albert Astals Cid wrote:
> El diumenge, 12 de novembre de 2017, a les 13:52:24 CET, Elvis Angelaccio va 
> escriure:
> > Hi,
> > where do I find the krazy source code? It doesn't seem to be listed under
> > https://cgit.kde.org/
> > 
> > Google tells me there is https://github.com/Krazy-collection/krazy but I'm
> > not sure if that is a mirror or a fork.
> 
> krazy fell into the "we're moving to github to have more contributors" trap.
> 
"It's a trap"

The official source is at https://github.com/Krazy-collection/krazy 
Actively developed by me.
Patches welcome.

Commit Notifications

[Allen Winter]

I still get email notifications on commits to a few repos.

How do I unsubscribe from the ones I no longer care about?
How do I subscribe to new repos I'm currently interested in?

searching the wiki isn't helping.
I see mention of CommitFilter, but that's dead.
I tried watching github mirrors, but that didn't work either.

Phab maybe?
not seeing anything obvious there either.

D7415: kconfig: kcfg.xsd do not require a kcfgfile

[Allen Winter]

winterz added a comment.


  comments? thoughts?

REPOSITORY
  R237 KConfig

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

To: winterz
Cc: #frameworks

Re: Review Request 129381: kconfig fix kconfigskeletontest

[Allen Winter]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129381/
---

(Updated Aug. 30, 2017, 4:08 p.m.)


Status
--

This change has been discarded.


Review request for KDE Frameworks.


Repository: kconfig


Description
---

some kconfigskeletontest tests were failing. this patch fixes:

1) rename init() and cleanup() to initTestCase() and cleanupTestCase() by 
convention and to make sure they happen in the correct order
2) testRemoveItem() must come after testKConfigDirty() becuase it removes the 
item we test for dirtyness
3) fix testSaveRead()


Diffs
-

  autotests/kconfigskeletontest.h 5cdcc9d 
  autotests/kconfigskeletontest.cpp 898366c 

Diff: https://git.reviewboard.kde.org/r/129381/diff/


Testing
---

before some of the tests fail and now they all pass.


Thanks,

Allen Winter

Re: KMarkdownWebView (kpart) in KDE Review

[Allen Winter]

One Krazy issue about making an explicit ctor, see
http://ebn.kde.org/krazy/reports/kdereview/kmarkdownwebview/src/index.html

I ran clazy too and it found no issues.

On Monday, August 21, 2017 6:18:19 PM EDT Friedrich W. H. Kossebau wrote:
> Hi,
> 
> KMarkdownWebView today entered KDE Review. This repo contains a kpart for 
> rendered display of Markdown files, using web technologies (webpage with 
> JavaScript library which creates HTML from the plaintext handed in).
> 
> I consider it rather a hack and would favour something done natively in Qt 
> (e.g. like the Markdown Okular generator in https://phabricator.kde.org/
> D7382). But for now it serves the use-case of providing a webpage-like 
> rendered display of markdown documents. Especially for the live preview 
> plugin for Kate & KDevelop currently worked on*.
> 
> * https://frinring.wordpress.com/2017/08/21/look-what-you-have-donewwdo
> 
> See also https://cgit.kde.org/kmarkdownwebview.git/about/
> 
> The separate library libKMarkdownWebView is done for sharing code with a 
> thumbnailer plugin, whose code yet is to be committed to this repo, as it 
> resists to work right now.
> 
> Initial build on CI looks good:
> https://build.kde.org/job/Extragear%20kmarkdownwebview%20kf5-qt5%20SUSEQt5.9/
> https://build.kde.org/job/Extragear%20kmarkdownwebview%20kf5-qt5%20FreeBSDQt5.7/
> 
> And people on #kde-devel & #kdevelop also reported successful builds and 
> usage.
> 
> 
> Target would be extragear/$SOMETHING, with $SOMETHING possibly "utils".
> 
> Initial release planned right after leaving kdereview.
> 
> Question: is there any appstream metadata possible for plugins?
> 
> Cheers
> Friedrich
> 

D7415: kconfig: kcfg.xsd do not require a kcfgfile

[Allen Winter]

winterz reclaimed this revision.
winterz added a comment.


  un-abandon.  I retested and it does work as intended

REPOSITORY
  R237 KConfig

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

To: winterz
Cc: #frameworks

D7415: kconfig: kcfg.xsd do not require a kcfgfile

[Allen Winter]

winterz abandoned this revision.
winterz added a comment.


  not good. ignore.

REPOSITORY
  R237 KConfig

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

To: winterz
Cc: #frameworks

D7415: kconfig: kcfg.xsd do not require a kcfgfile

[Allen Winter]

winterz created this revision.
Restricted Application added a project: Frameworks.
Restricted Application added a subscriber: Frameworks.

REVISION SUMMARY
  I'm seeing quite a few kconfigxt files that don't set the kcfgfile element.
  This patch changes the xsd so such files will validate.
  
  now you can have 0 or 1 setting of kcfgfile in a .kcfg file and it will still 
validate

TEST PLAN
  running xmllint against a bunch of .kcfgfiles, some with a kcfgfile element 
and some without

REPOSITORY
  R237 KConfig

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

AFFECTED FILES
  src/kconfig_compiler/kcfg.xsd

To: winterz
Cc: #frameworks

Re: kdesrc-build: git pre-commit hooks

[Allen Winter]

On Monday, July 31, 2017 9:05:09 PM EDT Michael Pyne wrote:
> On Sat, Jul 29, 2017 at 06:24:54PM -0400, Allen Winter wrote:
> > Howdy,
> > 
> > Is there a way to add a git hooks automagically with the git clones done by 
> > kdesrc-build?
> > 
> > I have a pre-commit hook that I'd like to have for all my kde src repos.
> > also I have a pre-push hook , but that's less important to me.
> > 
> > a post clone command, something as simple this would be enough:
> > ln -s  /path/to/my/githooks/pre-commit.py .git/hooks/pre-commit
> 
> That sounds fine by me.  This would probably be a kdesrc-buildrc config
> knob that the user should set... do you have an idea on what that would
> look like?  Path a user-defined command to run?  Path to a directory
> containing specially-named hooks?  Something else?
> 

actually, I think using the init.templatedir variable in ~/.gitconfig is the 
way to go.
I had forgotten about that.

kdesrc-build: git pre-commit hooks

[Allen Winter]

Howdy,

Is there a way to add a git hooks automagically with the git clones done by 
kdesrc-build?

I have a pre-commit hook that I'd like to have for all my kde src repos.
also I have a pre-push hook , but that's less important to me.

a post clone command, something as simple this would be enough:
ln -s  /path/to/my/githooks/pre-commit.py .git/hooks/pre-commit

D6936: ECMGeneratePriFile - mac os x framework builds of Qt

[Allen Winter]

winterz abandoned this revision.

REPOSITORY
  R240 Extra CMake Modules

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

To: winterz, dfaure
Cc: #frameworks, #build_system

D6936: ECMGeneratePriFile - mac os x framework builds of Qt

[Allen Winter]

winterz created this revision.
Restricted Application added projects: Frameworks, Build System.
Restricted Application added subscribers: Build System, Frameworks.

REVISION SUMMARY
  on mac os x framework builds of Qt, QT/include is not added to the list of 
include path,. this patch looks up one level so those includes can be found

TEST PLAN
  used the generated pri file on Mac

REPOSITORY
  R240 Extra CMake Modules

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

AFFECTED FILES
  modules/ECMGeneratePriFile.cmake

To: winterz, dfaure
Cc: #frameworks, #build_system

D6762: ECM: KDECompilerSettings LINKER_FLAGS on Cygwin

[Allen Winter]

winterz closed this revision.
winterz added a comment.


  see https://phabricator.kde.org/R240:db46fb7c2fdcfbff5f8a0445e4d055cf4388ead8

REPOSITORY
  R240 Extra CMake Modules

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

To: winterz, skelly, #build_system, #windows, kfunk
Cc: nalvarez, #frameworks, #build_system

D6762: ECM: KDECompilerSettings LINKER_FLAGS on Cygwin

[Allen Winter]

winterz added a comment.


  In https://phabricator.kde.org/D6762#126463, @nalvarez wrote:
  
  > Looks reasonable – although I wonder why on earth you're building KDE stuff 
on Cygwin...
  
  
  fun.  as an experiment. i'm curious.

REPOSITORY
  R240 Extra CMake Modules

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

To: winterz, skelly, #build_system, #windows, kfunk
Cc: nalvarez, #frameworks, #build_system

D6762: ECM: KDECompilerSettings LINKER_FLAGS on Cygwin

[Allen Winter]

winterz added reviewers: skelly, Build System.

REPOSITORY
  R240 Extra CMake Modules

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

To: winterz, skelly, #build_system
Cc: #frameworks, #build_system

D6762: ECM: KDECompilerSettings LINKER_FLAGS on Cygwin

[Allen Winter]

winterz created this revision.
Restricted Application added projects: Frameworks, Build System.
Restricted Application added subscribers: Build System, Frameworks.

REVISION SUMMARY
  Cygwin systems aren't ELF based so don't try to pass --enable-new-dtags to 
'ld'
  else you get 
/usr/lib/gcc/x86_64-pc-cygwin/5.4.0/../../../../x86_64-pc-cygwin/bin/ld: 
unrecognized option '--enable-new-dtags'

TEST PLAN
  see if I can build something on cygwin now

REPOSITORY
  R240 Extra CMake Modules

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

AFFECTED FILES
  kde-modules/KDECompilerSettings.cmake

To: winterz
Cc: #frameworks, #build_system

Re: Building kdelibs4support on Mac

[Allen Winter]

On Wednesday, June 7, 2017 4:04:13 PM EDT Garvit Khatri wrote:
> Hi,
> 
> I am trying to build kdelibs4support on MacOs Sierra (v10.12.4 Beta) all
> the dependencies are already built and installed using kdesrc-build. Now,
> when I try to build kdelibs4support using kdesrc-build I get the following
> error:
> 
> 
>1. /kde/usr/frameworks/kdelibs4support/src/kssl/ksslcertificate.h:105:38:
>error: unknown type name 'X509'
>2. static KSSLCertificate *fromX509(X509 *x5);
> 
> 
> Full build log can be found at: https://pastebin.com/6pWk27NR
> 
> Any help in building would be helpfull.
> 
brew install openssl
export OPENSSL_ROOT_DIR="/usr/local/opt/openssl";

D5828: fix plasma-frameworks build without kwayland

[Allen Winter]

winterz closed this revision.
winterz added a comment.


  committed  
https://phabricator.kde.org/R242:6c03c15c08a4b585bc3f320865858e4c2832f70b

REPOSITORY
  R242 Plasma Framework (Library)

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

To: winterz, mart, davidedmundson, bshah, #plasma
Cc: dfaure, asturmlechner, apol, #frameworks

D5975: breeze-icons: don't look for bash on Windows

[Allen Winter]

winterz closed this revision.
winterz added a comment.


  committed in 
https://phabricator.kde.org/R266:09291a2b3ecf03577b93c6d4cedc28927668e571

REPOSITORY
  R266 Breeze Icons

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

To: winterz, aacid
Cc: aacid, #frameworks

D5975: breeze-icons: don't look for bash on Windows

[Allen Winter]

winterz edited the summary of this revision.

REPOSITORY
  R266 Breeze Icons

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

To: winterz
Cc: aacid, #frameworks

D5975: breeze-icons: don't look for bash on Windows

[Allen Winter]

winterz added a comment.


  Because Hannah told me the script doesn't work on Windows.
  
  let's look at validate-svg.sh.
  you need a working unix 'find' command (not the WIndows find command) as well 
as xmllint for the bash script to work.

REPOSITORY
  R266 Breeze Icons

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

To: winterz
Cc: aacid, #frameworks

D5975: breeze-icons: don't look for bash on Windows

[Allen Winter]

winterz created this revision.
Restricted Application added a project: Frameworks.
Restricted Application added a subscriber: Frameworks.

REVISION SUMMARY
  The GoW package on Windows has bash.  We don't want to find bash on Windows.

REPOSITORY
  R266 Breeze Icons

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

AFFECTED FILES
  CMakeLists.txt

To: winterz
Cc: #frameworks

D5828: fix plasma-frameworks build without kwayland

[Allen Winter]

winterz created this revision.
Restricted Application added a project: Frameworks.
Restricted Application added a subscriber: Frameworks.

REVISION SUMMARY
  fixes the compile errors in plasmaquick/dialog.cpp if you don't have kwayland

TEST PLAN
  compile it

REPOSITORY
  R242 Plasma Framework (Library)

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

AFFECTED FILES
  src/plasmaquick/dialog.cpp

To: winterz, mart
Cc: #frameworks

D5646: Solve problem with microphone-sensitivity-medium

[Allen Winter]

winterz added a comment.


  my commit was a hack to get the validator to pass.  this patch is far more 
extensive.

REPOSITORY
  R266 Breeze Icons

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

To: patrickelectric, #kate, andreaska
Cc: ltoscano, winterz, #frameworks

D5456: KDoctools: build on Mac with docbook from homebrew

[Allen Winter]

winterz closed this revision.
winterz added a comment.


  committed in 
https://phabricator.kde.org/R238:5c5bfc2d838993f7d4be1885dff822e3794c529f

REPOSITORY
  R238 KDocTools

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

To: winterz, ltoscano, kfunk
Cc: kfunk, #frameworks, #documentation, skadinna

D5456: KDoctools: build on Mac with docbook from homebrew

[Allen Winter]

winterz updated this revision to Diff 13520.
winterz added a comment.


  I added comments.

REPOSITORY
  R238 KDocTools

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D5456?vs=13448=13520

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

AFFECTED FILES
  cmake/FindDocBookXML4.cmake
  cmake/FindDocBookXSL.cmake

To: winterz, ltoscano, kfunk
Cc: kfunk, #frameworks, #documentation, skadinna

D5456: KDoctools: build on Mac with docbook from homebrew

[Allen Winter]

winterz created this revision.
Restricted Application added projects: Frameworks, Documentation.
Restricted Application added subscribers: Documentation, Frameworks.

REVISION SUMMARY
  On Mac, homebrew installs the docbook-xml and docbook-xls files under 
/usr/local/opt
  so add searchpaths accordingly

TEST PLAN
  builds on Mac now after running brew install docbook docbook-xsl

REPOSITORY
  R238 KDocTools

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

AFFECTED FILES
  cmake/FindDocBookXML4.cmake
  cmake/FindDocBookXSL.cmake

To: winterz, ltoscano
Cc: #frameworks, #documentation, skadinna