D28093: [breeze-icons] add TeamViewer tray icons

[Ilya Bizyaev]

IlyaBizyaev added a comment.


  When I updated my parents' PC, they lost the TeamViewer desktop icon because 
it became monochrome.
  Confirmed locally, the TeamViewer icon in the Dashboard menu is also 
monochrome.
  This does not happen to the recently introduced Flameshot icon, so what's the 
difference here?

REPOSITORY
  R266 Breeze Icons

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

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

D29222: Fix update auto selection

[Dan Leinir Turthra Jensen]

leinir updated this revision to Diff 81412.
leinir added a comment.


  Thanks @ngraham, learn me to add debug information and then forget to commit 
it :P
  
  - Compile...

REPOSITORY
  R304 KNewStuff

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29222?vs=81318&id=81412

BRANCH
  fix-update-autoselection (branched from master)

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

AFFECTED FILES
  src/core/cache.cpp
  src/core/engine.cpp

To: leinir, #frameworks, #plasma, bugseforuns, ngraham
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

Re: Splitting KWayland

[David Edmundson]

On Tue, 28 Apr 2020, 07:24 Vlad Zahorodnii,  wrote:

> On 4/27/20 4:12 PM, David Edmundson wrote:
> > I don't think we want to remove client or server tests on this one. As
> > the client tests covered the server side too
>
> Hmm, does this mean we are going to keep both the client and the server
> side in KWaylandServer?
>

No.

We said we would build them against KWayland::Client

With the slow migration for the protocols to be against the new approach.

David

>
> Cheers,
> Vlad
>
>
>

D29101: KNewStuff: Fix file path and process call

[Dan Leinir Turthra Jensen]

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


  That's well spotted. Thanks for taking that one on :)

REPOSITORY
  R304 KNewStuff

BRANCH
  bugfix_uninstall (branched from master)

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

To: alex, #knewstuff, ngraham, nicolasfella, elvisangelaccio, meven, mlaurent, 
leinir
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D28701: Add KPackage support to KNewStuffCore

[Dan Leinir Turthra Jensen]

leinir added a comment.


  Ping team framework and such? (i realise we're all a tiny bit more stressy 
than usual...)

REPOSITORY
  R304 KNewStuff

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

To: leinir, #plasma, #knewstuff, #frameworks, ngraham, mart, davidedmundson, 
broulik, bshah
Cc: alex, ngraham, kde-frameworks-devel, LeGast00n, cblack, michaelh, bruns

D29232: [WIP][RFC]Introduce the Header color set

[Marco Martin]

mart added inline comments.

INLINE COMMENTS

> davidre wrote in kcolorscheme.cpp:271
> Because the new colors are the replacement for theses colors. I thought one 
> of those might map to this

i also added a question on the task, whether final colors are decided for it, 
they should go up here
https://phabricator.kde.org/T10201

REPOSITORY
  R265 KConfigWidgets

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

To: mart, #vdg, #plasma, cblack
Cc: davidre, ndavis, cblack, kde-frameworks-devel, LeGast00n, michaelh, 
ngraham, bruns

D28624: Print a warning if runner is incompatible with KRunner

[Kai Uwe Broulik]

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


  Would be lovely if we could get this date parsing into `QVersionNumber` of 
`KFormat`, I'm seeing similar code also in kscreenlocker, kwin, libksysguard, 
...

REPOSITORY
  R308 KRunner

BRANCH
  warning (branched from master)

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

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

D29153: Move handling of untrusted programs to ApplicationLauncherJob.

[Kai Uwe Broulik]

broulik accepted this revision.
broulik added inline comments.
This revision is now accepted and ready to land.

INLINE COMMENTS

> applicationlauncherjob.cpp:155
> +}
> +proceedAfterSecurityChecks();
> +}

With this it starts to look as hard to follow as KRun :)

REPOSITORY
  R241 KIO

BRANCH
  2020_04_UntrustedProgramHandler

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

To: dfaure, ahmadsamir, broulik, ngraham, mdlubakowski
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

Re: KF 5 & C++14?

[ahiemstra]

On Monday, 27 April 2020 14:53:32 CEST Friedrich W. H. Kossebau wrote:
> Am Montag, 27. April 2020, 00:45:41 CEST schrieb David Faure:
> > On Sunday, April 26, 2020 5:30:37 PM CEST Friedrich W. H. Kossebau wrote:
> > > Hi,
> > > 
> > > I just saw that at least kimageformats, knewstuff & kquickcharts all set
> > > this: set(CMAKE_CXX_STANDARD 14)
> > > 
> > > set(CMAKE_CXX_STANDARD_REQUIRED ON)
> > > 
> > > Which ignores a bit that so far C++11 has been the minimum standard
> > > officially supported in/by KDE Frameworks (by mainly following what Qt 5
> > > supports).
> > > 
> > > Compare also the current text of the policy
> > > "Frameworks compiler requirements and C++11":
> > > --- 8< ---
> > > The following minimal compiler versions are supported by KDE Frameworks:
> > > * GCC 4.8
> > > * Clang 3.3
> > > * VS2013 (MSVC12)
> > > 
> > > This means all of the C++11 standards can be used.
> > > --- 8< ---
> > > * https://community.kde.org/Frameworks/
> > > Policies#Frameworks_compiler_requirements_and_C.2B.2B11
> > > 
> > > What to make of this? Might it be the time to raise the bars a bit, and
> > > how
> > > much? Surely the lower limit is what the oldest Qt version currently
> > > supported by KDE Frameworks claims to support:
> > > https://doc.qt.io/qt-5.12/supported-platforms.html
> > > 
> > > Should we go above this?
> > > Or should kimageformats, knewstuff & kquickcharts be fixed to use C++11
> > > only again?
> > > 
> > > No own opinion, so far only stumbled over what seems a policy breakage.
> > 
> > The goal was to align with the requirements of the Qt version we require.
> > 
> > But it's hard to know if anyone is actually using gcc 4.8 to build the
> > current version of KF5. One way to find out is to... do nothing. Leave the
> > above as is and see if anyone actually complains that it doesn't match our
> > promise.
> 
> For reference, the CMAKE_CXX_STANDARD 14 is present in those modules...
> KQuickCharts:  since KF 5.65 (== addition of module)
> KNewStuff: since KF 5.69
> KImageFormats: since KF 5.70
> So relatively new, meaning the field observation phase only just began :)
> 

The reason Quick Charts is using C++14 is that I seem to remember that being 
the minimum required version for Frameworks. But apparently I was mistaken, 
might have been me mixing up Plasma and Frameworks requirements.

> > This isn't however a green light for doing this everywhere, not until we
> > wait multiple months for feedback. Otherwise the porting effort (down to
> > C++11) will be huge.
> 
> One personal motivation to ask was the hope that we could go C++14 across
> all KF modules now. Not needing to support C++11 anymore, but relying on
> C++14 deprecation tagging features would simplify ECMGenerateExportHeader
> code and, what triggered me here, make it simple to extend version-based
> deprecation tagging also for enumerators.
> Guess I am out of luck then for now, or have to post-pone the feature :)

Personally, I'd be in favour of ramping up required C++ version support in 
light of the requirement of C++17 for Qt 6. So require 14 now, require 17 once 
Qt 6 is out. That way you're taking care of one bit of the transition before 
Qt 6 actually hits.

Note also that Qt 5.14 already stopped supporting GCC <5 [1] (which is the 
version that supports C++14 fully) and even for 5.12 GCC 5 versions are better 
supported [2].

- Arjen

> 
> Cheers
> Friedrich

[1]: https://codereview.qt-project.org/c/qt/qtdoc/+/288825
[2]: https://doc.qt.io/qt-5.12/linux.html

D28353: Changed contrast effect values to have more transparency, and then changed transparency accordingly

[Filip Fila]

filipf added a comment.


  LGTM

REPOSITORY
  R242 Plasma Framework (Library)

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

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

Re: Information regarding upcoming Gitlab Migration

[Ben Cooksley]

On Tue, Apr 28, 2020 at 11:09 PM Adriaan de Groot  wrote:
>
> There are a whole bunch of considerations and use-cases being discussed at
> once in this thread, and Leinir's post made me think a bit about different
> actors can interact with "the collection of repositories".
>
> One actor is "tooling", as Albert has pointed out. Whatever the resulting
> structure is, it needs to be communicated to tool authors on time for tools to
> be updated, released, and rolled out for use. Tools mentioned so far:
>  - kdesrc-build
>  - i18n / scripty
>  - release scripts
> The tools don't have An Opinion regarding the layout, they just need to be
> updated.
>
> A tool-like actor that I don't think has been mentioned so far is "existing
> checkouts". I have a src/kde with all the bits I've looked at "recently".
> There may even be some SVN checkouts there -- I'm willing to forget about
> those. Surprising and annoying me every time I update those sometime in the
> future is not good, but it's only going to annoy me once (per repo, so at most
> 143 times for my clones).
>
> I'd be *vaguely* worried about existing crontabs and automatic jobs that we've
> forgotten about, or which others have forgotten about. Those aren't fixable in
> the face of any changes to repositories, anyway.
>
>
> Turning to human actors, who are the more interesting ones,
>
> On 2020 prilula d. 28id 10:38:36 CEST Dan Leinir Turthra Jensen wrote:
> > On Monday, 27 April 2020 21:25:09 BST Albert Astals Cid wrote:
> > > El dilluns, 27 d’abril de 2020, a les 13:58:02 CEST, Bhushan Shah va
> > > > On Mon, Apr 27, 2020 at 12:38:42PM +0200, Aleix Pol wrote:
> > > > > Does this mean that to clone it we'll have to go "git clone
> > > > > kde:games/knetwalk" or something along the lines?
>
> > > > > If that's the case I'd much prefer if we didn't do this, at the moment
> > > > > it's already uncomfortable for me to remember the URL for some of the
> > > > > repos (e.g. is it sysadmin/ or not?), this will only increase the
> > > > > problem and I personally don't see the advantage.
>
>
> Humans come in all shapes and sizes; here's one called Aleix who likes to
> remember the name of a thing, one single label. (Ironic: this particular Aleix
> is also labelled "Aleix Pol" and possibly "Aleix Pol Gonzales") The question
> I'd ask is "in what **context** do you need to remember the URL of a repo?"
> and for that matter: "why is 'knetwalk' an obvious thing to remember, and
> 'games/knetwalk' not-obvious?"
>
> Context here can mean many things. In this thread we've had mentioned:
>  - people just browsing and wanting A Big List
>Here a hierarchical approach means more clicks and navigating a tree,
>rather than a flat structure.
>  - people browsing for a known label
>Using ^F in a flat list or some search field (see also Ian Wadham's
>message just now) doesn't seem *that* different to me, although I've
>got to give ^F the benefit of speed and simplicity.
>  - developers sharing a task list and reviews
>
> .. probably more. Some of these roles have, depending on the chosen solution,
> problems that can be solved with a *technical* addition
> (bigflatlistofrepositories.kde.org .. or whatever), others are going to need a
> social solution.
>
>
>
> Personally, I'm with Leinir here:
>
> > Just adding my "i don't use kdesrc-build, and git clone kde:x everything
> > myself" voice, here.
>
> Perhaps it's the "old school", but kdesrc-build doesn't do anything for me.
> I'm intermittently interested in the source of some random part of KDE --
> generally because it's mentioned on IRC -- and then I need that source where I
> can look at it. Whether it's 'git clone' or 'kdesrc-build --just-the-source-
> please' doesn't matter much.
>
> If there's any compiling to be done, the less magic there is between me and
> the compile, the better.
>
> So, yeah: `git clone kde:x` all the way, but I'm also not really invested in
> the structure of the label x, or the precise configuration of kde:.
>
>
> > Now, if a simple(ish) script can be created to make
> > something akin to the kde: rewriting work, even if what it really does is to
> > search gitlab and create a clone with the appropriate command, i could deal
> > with that, but having the ability to simply ask for the project name is
> > more than a little useful.
>
> I think we shouldn't underestimate how names are a social construct, though:
> the current flat structure comes after a structured SVN naming epoch. But I'd
> totes +1 a search-and-redirector, especially if it means I can write `git
> clone kde:peruse` and the resulting .git/config has followed the redirects and
> whatnot and ended up with `url: kdeforreal:audio/peruse`

Would some form of git alias/custom command script that works similar
to the following be suitable?

git kde-clone skrooge

That script would then search the appropriate groups (ignoring any
personal repositories including forks), find the necessary repository
and perform the clone a

Re: Information regarding upcoming Gitlab Migration

[Bhushan Shah]

Hi Adriaan,

On Tue, Apr 28, 2020 at 01:08:33PM +0200, Adriaan de Groot wrote:
> A tool-like actor that I don't think has been mentioned so far is "existing 
> checkouts". I have a src/kde with all the bits I've looked at "recently". 
> There may even be some SVN checkouts there -- I'm willing to forget about 
> those. Surprising and annoying me every time I update those sometime in the 
> future is not good, but it's only going to annoy me once (per repo, so at 
> most 
> 143 times for my clones).

We have a plan to provide a script which can change remotes in existing
clones. (It would take a top-level directory path for all your clones).

> Perhaps it's the "old school", but kdesrc-build doesn't do anything for me. 
> I'm intermittently interested in the source of some random part of KDE -- 
> generally because it's mentioned on IRC -- and then I need that source where 
> I 
> can look at it. Whether it's 'git clone' or 'kdesrc-build --just-the-source-
> please' doesn't matter much.
> 
> If there's any compiling to be done, the less magic there is between me and 
> the compile, the better.
> 
> So, yeah: `git clone kde:x` all the way, but I'm also not really invested in 
> the structure of the label x, or the precise configuration of kde:.
> 
> 
> > Now, if a simple(ish) script can be created to make
> > something akin to the kde: rewriting work, even if what it really does is to
> > search gitlab and create a clone with the appropriate command, i could deal
> > with that, but having the ability to simply ask for the project name is
> > more than a little useful.
> 
> I think we shouldn't underestimate how names are a social construct, though: 
> the current flat structure comes after a structured SVN naming epoch. But I'd 
> totes +1 a search-and-redirector, especially if it means I can write `git 
> clone kde:peruse` and the resulting .git/config has followed the redirects 
> and 
> whatnot and ended up with `url: kdeforreal:audio/peruse`

One thing to remember is, you can't really have a dynamic insteadOf URL
setup. Besides, even if we had a everything under KDE namespace I'd find
a setup for this weird enough.

Let's assume that everything is under invent.kde.org/kde (and
invent.kde.org/sysadmin and invent.kde.org/websites as it is right now).

Now you add a following snippet in gitconfig,

 [url "https://invent.kde.org/KDE/";]
 insteadOf = kde:
 [url "g...@invent.kde.org:KDE/"]
 pushInsteadOf = kde:

Which is slightly modified version of the existing kde: URL helper shown here,
https://community.kde.org/Sysadmin/GitKdeOrgManual#Let_Git_rewrite_URL_prefixes

Now this is perfectly fine for the something which is kde/ so you can do
git clone kde:krita and it would happily replace 'kde:' part with
'https://invent.kde.org/KDE/' and would clone 
'https://invent.kde.org/KDE/krita' 

But, now things get interesting when you want to clone the
docs-krita-org which is in the websites/ namespace. We will have to keep
this things in separate namespace for policy reasons (and same goes for
sysadmin stuff). How would you clone docs-krita-org?

git clone kde:../websites/krita-org ?
add a separate prefix for websites and sysadmin?

Let's assume that you added snippet for sysadmin and websites, it's
just 8 more lines after all,

 [url "https://invent.kde.org/websites/";]
 insteadOf = websites:
 [url "g...@invent.kde.org:websites/"]
 pushInsteadOf = websites:
 [url "https://invent.kde.org/sysadmin/";]
 insteadOf = sysadmin:
 [url "g...@invent.kde.org:sysadmin/"]
 pushInsteadOf = sysadmin:

Does this solve all use-cases? I believe no, it still does not support
the personal repositories of users. So you also need to add 4 more lines
for your own user, and 4 for each user whose repository you want to
clone.

What our workflow with the kde: prefix so far had been really useful I
agree, and I will miss it, but with departure of gitolite which allowed
repositories at top-level, we can't easily support this, and we have to
accept it.

Perhaps solution suggested by Ben in his email could be useful instead
and in addition generic invent: snippet which does not include any
namespace.

 [url "https://invent.kde.org/";]
 insteadOf = invent:
 [url "g...@invent.kde.org:"]
 pushInsteadOf = invent:

> (That said, bigflatlistofrepositories.kde.org .. or maybe call it 
> cgit.kde.org 
> .. could be a particular view onto gitlab which does flattening and search, 
> but only if there's people around to create it and maintain it)

Just to clarify, sysadmins have no plan to support or maintain the cgit
instance once we migrate to Gitlab.

Thanks

-- 
Bhushan Shah
http://blog.bshah.in
IRC Nick : bshah on Freenode
GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D


signature.asc
Description: PGP signature

D29251: API dox: use ulong typedef with Q_PROPERTY(percent) to avoid doxygen bug

[Friedrich W. H. Kossebau]

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

REVISION SUMMARY
  See https://github.com/doxygen/doxygen/issues/7734

REPOSITORY
  R244 KCoreAddons

BRANCH
  fixkjobpercentdocs

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

AFFECTED FILES
  src/lib/jobs/kjob.h

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

D29251: API dox: use ulong typedef with Q_PROPERTY(percent) to avoid doxygen bug

[Friedrich W. H. Kossebau]

kossebau added a comment.


  Given `unsigned long` is 32 bit on some systems and 64 bit on others, perhaps 
this should also get a KF6 TODO to use a different type. 32 bit might be enough 
in general for the percent value, no?

REPOSITORY
  R244 KCoreAddons

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

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

D29254: [RenameDialog] Add an arrow indicating direction from src to dest

[Ahmad Samir]

ahmadsamir created this revision.
ahmadsamir added reviewers: Frameworks, dfaure, meven.
Herald added a project: Frameworks.
ahmadsamir requested review of this revision.

REVISION SUMMARY
  This adds a visual indication to show the direction of the copy/move..etc
  operation pointing from source to destination.
  
  See the screenshot.
  
  BUG: 268600

REPOSITORY
  R241 KIO

BRANCH
  l-srt-to-dest (branched from master)

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

AFFECTED FILES
  src/widgets/renamedialog.cpp

To: ahmadsamir, #frameworks, dfaure, meven
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29254: [RenameDialog] Add an arrow indicating direction from src to dest

[Ahmad Samir]

ahmadsamir edited the summary of this revision.

REPOSITORY
  R241 KIO

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

To: ahmadsamir, #frameworks, dfaure, meven
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29254: [RenameDialog] Add an arrow indicating direction from src to dest

[Ahmad Samir]

ahmadsamir added a comment.


  I tried with Arabic, and the rename dialog had some Arabic text, but the 
layout was still LTR (can it switch to RTL?).

REPOSITORY
  R241 KIO

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

To: ahmadsamir, #frameworks, dfaure, meven
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29256: [server] Introduce mapped() signal

[Vlad Zahorodnii]

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

REVISION SUMMARY
  In KWin, we need to know when a sub-surface becomes mapped or unmapped
  so we can generate or filter out window quads for the sub-surface.

REPOSITORY
  R127 KWayland

BRANCH
  introduce-mapped-signal

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

AFFECTED FILES
  autotests/client/test_wayland_surface.cpp
  src/server/surface_interface.cpp
  src/server/surface_interface.h

To: zzag, #kwin
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29101: KNewStuff: Fix file path and process call

[Anthony Fieroni]

anthonyfieroni added inline comments.

INLINE COMMENTS

> installation.cpp:610
> +QStringList args = KShell::splitArgs(command);
> +int exitcode = QProcess::execute(args.takeFirst(), args);
>  

Get program in exclusive line

  auto program = args.takeFirst();
  int exitcode = QProcess::execute(program, args);

The problem is args is modified at argument pass time, then second parameter 
expect it is. That's not guaranteed you should expect compiler to do the right 
thing.

REPOSITORY
  R304 KNewStuff

BRANCH
  bugfix_uninstall (branched from master)

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

To: alex, #knewstuff, ngraham, nicolasfella, elvisangelaccio, meven, mlaurent, 
leinir
Cc: anthonyfieroni, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, 
bruns

D29256: [server] Introduce mapped() signal

[David Edmundson]

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

REPOSITORY
  R127 KWayland

BRANCH
  introduce-mapped-signal

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

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

Re: Splitting KWayland

[Aleix Pol]

On Mon, Apr 27, 2020 at 2:57 PM Aleix Pol  wrote:
>
> Hi,
> As discussed in the meeting last week, I've been looking into the split.
>
> Here's what I was thinking of, please tell me if there's something
> massively important I'm missing.
>
> The idea would be to start working on it after kwayland and other kf5
> have been tagged next week (?).
>
> Something I was wondering too is that I guess the new repos should end
> up in invent? Although neither plasma or kf5 are there.
> So maybe not?
>
> There's a couple of questions below as well, thoughts would be welcome
>
> Aleix
>
> git clone kde:kwayland
> mv kwayland plasma-wayland-protocols
> cd plasma-wayland-protocols
> git rm -r autotests/ docs/ tests/ src/
> # fix build
> # close https://phabricator.kde.org/T13024
>
> git clone kde:kwayland
> mv kwayland/ kwayland-server
> git rm -r src/client/
> # namespace KWayland::Server -> namespace KWaylandServer
> # fix build
> # remove server tests?
> # see to move things to KWin?
> # close https://phabricator.kde.org/T13025
>
> git clone kde:kwayland
> # deprecate all KWayland::Server
> # remove server tests?

Here's an implementation of above:
https://invent.kde.org/apol/plasma-wayland-protocols
https://invent.kde.org/apol/kwayland-server

My suggestion as next steps is to turn these into proper KDE
repositories in its own right soon and develop master kwin and plasma
overall against these.

When 5.19 needs releasing, then the wayland protocol would be included in KF5.

Can someone take a look and tell me if it's what they expected? If so
I'll proceed to request the repositories and start talking to the
different stakeholders.

Aleix

Re: Splitting KWayland

[David Edmundson]

That is what I imagined.

The protocols section contains some things we can strip down.
We shouldn't host anything that's in wayland-protocols like text-input.
Also I think there's some dead things like plasma-effects.

But we can do that sort of thing anytime before the first release.

David

Re: Information regarding upcoming Gitlab Migration

[Ian Wadham]

Um, guys… Google is your friend...

I am a former KDE Games developer. I play KPatience quite a lot, as well as 
other games to keep my brain active, especially during COVID-19 lockdown. 
Recently I thought I could see where the answer lay to three bugs in the 
solver(s), two in the Forty Eight variant and one, very recently reported, in 
the Klondike variant. So I thought I would have a look at the source code to 
see if my hypotheses might be correct and maybe work out a patch.

My first problem was to track down where the repos that I need are and how to 
clone read-only copies. I didn’t even know what websites they are on any more 
and KPatience is actually called kpat in the code (which I remembered). However 
I can google “source code KDE KPatience” and the pat repository comes up as the 
first hit, presumably because “KPatience” is used in the repository’s 
description. Again “… card games” got the repo as hit 2 and “… solitaire” (the 
American term for such games) got it as the first hit.

I have also found that several of the tricky cases mentioned earlier in this 
thread can be resolved with Google search terms beginning “source code KDE 
xxx”. For example, seeing xxx as “Plasma Mobile” get the repo as hit 2. And 
just using “go” as xxx finds the Kigo repository as hit 3. Even a search with 
xxx = “loderunner” finds the KGoldRunner repository as hit 1, even though 
Loderunner is not mentioned in the repository’s description. I wonder how far 
down repositories Google indexing goes. Even using xxx = “lode runner” (2 
words), as suggested by Google, finds the KGoldrunner Handbook, though not the 
repository. Still, a smart newbie might guess the name used for that type of 
game in KDE and refine his source code search accordingly.

Even after I found the kpat repository, I could not understand where the souce 
code was getting the card decks it uses. I knew from memory that they are in 
some library somewhere, but there is no libkdecards. Googling with xxx = 
something like “library cards” found the cards as a sub-directory of the 
libkdegames repository.

So my suggestion is to keep whatever categories you like, including multiple 
categories as required, as long as the category names are in plain English, not 
KDE jargon. In addition, please continue to pepper repository descriptions with 
search terms (words) that are easy for laymen and non-core KDE developers to 
find.

Another possibility is to construct (automatically) a text-file “catalog” with 
one line for each of the 1000+ repositories, containing (at least) the repo 
name and description, but maybe other keywords. Then people could just “grep” 
and “sort” it to find what they wanted. 

My 2 cents,
Ian Wadham.

> On 28 Apr 2020, at 2:46 pm, Bhushan Shah  wrote:
> 
> Hi Olivier,
> 
> On Mon, Apr 27, 2020 at 10:49:46PM +0200, Olivier Churlaud wrote:
>>> Because in order to search for something, you need to know it exists.
>>> 
>>> If you are just casually browsing, then the search can't help you.
>> 
>> I don't think people casually browse our repos. What use case is more likely 
>> to happen and do we want to support? 
> 
> We don't really want to discard use-cases just because it does not suit
> our workflow. That is not how we are going to gain new contributors, we
> should value each contribution, be it drive-by contribution, or focused
> contribution towards one single project.
> 
>> Use case 1 : Jerry learns about KDE and go in their forge in the Multimedia 
>> section. After carefully reading the code of two applications and three libs 
>> he starts contributing to Elisa. 
>> 
>> Use case 2 : While using her Ubuntu installation of Elisa / while reading on 
>> reddit about Elisa, Jerry decides to try to contribute to this project/fix 
>> this bug that itches her and searches for it in KDE's forge. 
> 
> Let me add a some more usecases, some of which I've been dealing with in
> project I maintain.
> 
> Use case 3 : Tom comes in Plasma Mobile channel and asks for Plasma
> Mobile applications source code
> 
> Use case 4 : Tom is a student in Germany and is interested in
> contributing to wikitolearn, and he asks where can I find code of the
> wikitolearn?
> 
> Suggestion offered by sysadmin team does not cater to one single
> use-case, but offers a way to provide a solution to all 4 usecases. For
> Plasma Mobile team or Wikitolearn team it would be much easier to refer
> contributors to the https://invent.kde.org/plasma-mobile or
> https://invent.kde.org/wikitolearn then tell them to go to
> https://invent.kde.org/KDE and search for the tag wikitolearn or Plasma
> Mobile.
> 
>> On the other hand, I think the discussion about spotting open merge requests 
>> (in a derived thread from this one) should be answered, being by relevant 
>> tags, subgroups or whatever. 
> 
> (super personal note)
> 
> Ironically, Usecase 1 is how I started contributing to KDE 7 years back.
> While I was inspired by battery monitor re-design in 4.11 release, I

Re: Information regarding upcoming Gitlab Migration

[Adriaan de Groot]

There are a whole bunch of considerations and use-cases being discussed at 
once in this thread, and Leinir's post made me think a bit about different 
actors can interact with "the collection of repositories".

One actor is "tooling", as Albert has pointed out. Whatever the resulting 
structure is, it needs to be communicated to tool authors on time for tools to 
be updated, released, and rolled out for use. Tools mentioned so far:
 - kdesrc-build
 - i18n / scripty
 - release scripts
The tools don't have An Opinion regarding the layout, they just need to be 
updated.

A tool-like actor that I don't think has been mentioned so far is "existing 
checkouts". I have a src/kde with all the bits I've looked at "recently". 
There may even be some SVN checkouts there -- I'm willing to forget about 
those. Surprising and annoying me every time I update those sometime in the 
future is not good, but it's only going to annoy me once (per repo, so at most 
143 times for my clones).

I'd be *vaguely* worried about existing crontabs and automatic jobs that we've 
forgotten about, or which others have forgotten about. Those aren't fixable in 
the face of any changes to repositories, anyway.


Turning to human actors, who are the more interesting ones,

On 2020 prilula d. 28id 10:38:36 CEST Dan Leinir Turthra Jensen wrote:
> On Monday, 27 April 2020 21:25:09 BST Albert Astals Cid wrote:
> > El dilluns, 27 d’abril de 2020, a les 13:58:02 CEST, Bhushan Shah va
> > > On Mon, Apr 27, 2020 at 12:38:42PM +0200, Aleix Pol wrote:
> > > > Does this mean that to clone it we'll have to go "git clone
> > > > kde:games/knetwalk" or something along the lines?

> > > > If that's the case I'd much prefer if we didn't do this, at the moment
> > > > it's already uncomfortable for me to remember the URL for some of the
> > > > repos (e.g. is it sysadmin/ or not?), this will only increase the
> > > > problem and I personally don't see the advantage.


Humans come in all shapes and sizes; here's one called Aleix who likes to 
remember the name of a thing, one single label. (Ironic: this particular Aleix 
is also labelled "Aleix Pol" and possibly "Aleix Pol Gonzales") The question 
I'd ask is "in what **context** do you need to remember the URL of a repo?" 
and for that matter: "why is 'knetwalk' an obvious thing to remember, and 
'games/knetwalk' not-obvious?"

Context here can mean many things. In this thread we've had mentioned:
 - people just browsing and wanting A Big List
   Here a hierarchical approach means more clicks and navigating a tree,
   rather than a flat structure.
 - people browsing for a known label
   Using ^F in a flat list or some search field (see also Ian Wadham's
   message just now) doesn't seem *that* different to me, although I've
   got to give ^F the benefit of speed and simplicity.
 - developers sharing a task list and reviews

.. probably more. Some of these roles have, depending on the chosen solution, 
problems that can be solved with a *technical* addition 
(bigflatlistofrepositories.kde.org .. or whatever), others are going to need a 
social solution.



Personally, I'm with Leinir here:

> Just adding my "i don't use kdesrc-build, and git clone kde:x everything
> myself" voice, here. 

Perhaps it's the "old school", but kdesrc-build doesn't do anything for me. 
I'm intermittently interested in the source of some random part of KDE -- 
generally because it's mentioned on IRC -- and then I need that source where I 
can look at it. Whether it's 'git clone' or 'kdesrc-build --just-the-source-
please' doesn't matter much.

If there's any compiling to be done, the less magic there is between me and 
the compile, the better.

So, yeah: `git clone kde:x` all the way, but I'm also not really invested in 
the structure of the label x, or the precise configuration of kde:.


> Now, if a simple(ish) script can be created to make
> something akin to the kde: rewriting work, even if what it really does is to
> search gitlab and create a clone with the appropriate command, i could deal
> with that, but having the ability to simply ask for the project name is
> more than a little useful.

I think we shouldn't underestimate how names are a social construct, though: 
the current flat structure comes after a structured SVN naming epoch. But I'd 
totes +1 a search-and-redirector, especially if it means I can write `git 
clone kde:peruse` and the resulting .git/config has followed the redirects and 
whatnot and ended up with `url: kdeforreal:audio/peruse`

(That said, bigflatlistofrepositories.kde.org .. or maybe call it cgit.kde.org 
.. could be a particular view onto gitlab which does flattening and search, 
but only if there's people around to create it and maintain it)

[ade]

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

Re: Information regarding upcoming Gitlab Migration

[Dan Leinir Turthra Jensen]

On Monday, 27 April 2020 21:25:09 BST Albert Astals Cid wrote:
> El dilluns, 27 d’abril de 2020, a les 13:58:02 CEST, Bhushan Shah va 
escriure:
> > In part I am mostly re-iterating what Ben already mentioned in different
> > messages.
> > 
> > On Mon, Apr 27, 2020 at 12:38:42PM +0200, Aleix Pol wrote:
> > > Does this mean that to clone it we'll have to go "git clone
> > > kde:games/knetwalk" or something along the lines?
> > 
> > Yes
> > 
> > [Rest of message is with sysadmin hat off and as a developer]
> > 
> > > If that's the case I'd much prefer if we didn't do this, at the moment
> > > it's already uncomfortable for me to remember the URL for some of the
> > > repos (e.g. is it sysadmin/ or not?), this will only increase the
> > > problem and I personally don't see the advantage.
> > 
> > I do agree that it maybe small inconvience, but let's be honest, most of
> > us have been using kdesrc-build or some kind of automated tooling for
> > building everything, apart from very rare case we never have to manually
> > clone any of KDE repository, at least it is true for me personally. I am
> > not sure about others.
> 
> Please let's refrain from saying things like "most of us have been using
> kdesrc-build" when you don't have any data to back that up.
> 
> Cheers,
>   Albert

Just adding my "i don't use kdesrc-build, and git clone kde:x everything 
myself" voice, here. Now, if a simple(ish) script can be created to make 
something akin to the kde: rewriting work, even if what it really does is to 
search gitlab and create a clone with the appropriate command, i could deal 
with that, but having the ability to simply ask for the project name is more 
than a little useful.

-- 
..dan / leinir..
http://leinir.dk/

D29254: [RenameDialog] Add an arrow indicating direction from src to dest

[Nathaniel Graham]

ngraham added a comment.


  Maybe this helps for RTL?
  
  https://doc.qt.io/qt-5.9/qtwidgets-tools-i18n-mainwindow-cpp.html

INLINE COMMENTS

> renamedialog.cpp:302
> +const int size = d->m_srcPreview->height();
> +const QPixmap pix = 
> QIcon::fromTheme(QStringLiteral("go-next")).pixmap(size);
> +d->m_srcToDestArrow->setPixmap(pix);

If you figure out how to make it RTL aware, you could toggle between the 
`go-next-symbolic` and `go-next-rtl-symbolic` icons

REPOSITORY
  R241 KIO

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

To: ahmadsamir, #frameworks, dfaure, meven
Cc: ngraham, kde-frameworks-devel, LeGast00n, cblack, michaelh, bruns

D29027: Move document corner fold to top right in two icons

[Nathaniel Graham]

ngraham added a comment.


  Shipit!

REPOSITORY
  R266 Breeze Icons

BRANCH
  update-document-close

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

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

D29163: RFC: Add document-replace icon (Like for Overwrite action)

[Nathaniel Graham]

ngraham added a comment.


  Personally I like the design.
  
  All rules are flexible; if the guideline to leave 1px of space is getting in 
the way, feel free to ignore if it the result looks better.

REPOSITORY
  R266 Breeze Icons

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

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

D29254: [RenameDialog] Add an arrow indicating direction from src to dest

[Ahmad Samir]

ahmadsamir added a comment.


  I meant it worked with Arabic, the direction was the same, just the text is 
translated, so the renamedialog and dolphin aren't RTL AFAICS.

REPOSITORY
  R241 KIO

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

To: ahmadsamir, #frameworks, dfaure, meven
Cc: ngraham, kde-frameworks-devel, LeGast00n, cblack, michaelh, bruns

D28093: [breeze-icons] add TeamViewer tray icons

[Nathaniel Graham]

ngraham added a comment.


  Oh gosh, Can confirm. :/
  
  Now we have two icons with different casing: `teamviewer` (colorful, app 
icon) and `TeamViewer` (monochrome, tray icon). I guess the app uses the same 
icon name for its tray icon as its main icon (b) and also KIconLoader isn't 
case-sensitive (b)? Yikes, what a mess. :/ Not sure what we do here TBH

REPOSITORY
  R266 Breeze Icons

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

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

D29258: Don't use notifybysnore.h on MSYS2

[Łukasz Wojniłowicz]

wojnilowicz created this revision.
wojnilowicz added reviewers: broulik, brute4s99.
wojnilowicz added a project: Frameworks.
wojnilowicz requested review of this revision.

REVISION SUMMARY
  SnoreToast fails to build on MSYS2 due to missing
  which apparently is not available for this compiler.
  
  This patch changes dependency on SnoreToast from required to optional.
  As a result, it allows to actually build KNotifications on MSYS2.

TEST PLAN
  Built application on Windows, which links to KNotifications.

REPOSITORY
  R289 KNotifications

BRANCH
  master

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

AFFECTED FILES
  CMakeLists.txt
  src/CMakeLists.txt
  src/config-knotifications.h.cmake
  src/knotificationmanager.cpp

To: wojnilowicz, broulik, brute4s99
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D28093: [breeze-icons] add TeamViewer tray icons

[David Redondo]

davidre added a comment.


  Couldn't we put the tray icon in the plasma theme?

REPOSITORY
  R266 Breeze Icons

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

To: rocka, #vdg, ngraham, ndavis
Cc: davidre, IlyaBizyaev, ngraham, ndavis, kde-frameworks-devel, LeGast00n, 
cblack, michaelh, bruns

D29254: [RenameDialog] Add an arrow indicating direction from src to dest

[Nathaniel Graham]

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

REPOSITORY
  R241 KIO

BRANCH
  l-srt-to-dest (branched from master)

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

To: ahmadsamir, #frameworks, dfaure, meven, ngraham
Cc: ngraham, kde-frameworks-devel, LeGast00n, cblack, michaelh, bruns

D29259: Missed a date on previous update

[Sorin Ionescu]

sionescu created this revision.
sionescu created this object with edit policy "Subscribers".
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
sionescu requested review of this revision.

REVISION SUMMARY
  Modified the day for Ziua mamei from may 8 to may 3, somehow I missed this in 
my previous update

REPOSITORY
  R175 KHolidays

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

AFFECTED FILES
  holidays/plan2/holiday_ro_ro

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

D29256: [server] Introduce mapped() signal

[Aleix Pol Gonzalez]

apol added a comment.


  +1

INLINE COMMENTS

> surface_interface.cpp:333
>  const bool childrenChanged = source->childrenChanged;
> +const bool visibilityChanged = bool(source->buffer) ^ 
> bool(target->buffer);
>  bool sizeChanged = false;

Using != would probably be more readable and accurate (we're don't need it to 
be bitwise, we're assuming bool changes it to 1 or 0).

REPOSITORY
  R127 KWayland

BRANCH
  introduce-mapped-signal

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

To: zzag, #kwin, davidedmundson
Cc: apol, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29256: [server] Introduce mapped() signal

[Vlad Zahorodnii]

zzag updated this revision to Diff 81453.
zzag added a comment.


  Check whether the attached buffer flip-flopped between non-null and null only 
when bufferChanged is true.

REPOSITORY
  R127 KWayland

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29256?vs=81432&id=81453

BRANCH
  introduce-mapped-signal

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

AFFECTED FILES
  autotests/client/test_wayland_surface.cpp
  src/server/surface_interface.cpp
  src/server/surface_interface.h

To: zzag, #kwin, davidedmundson
Cc: apol, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29256: [server] Introduce mapped() signal

[Vlad Zahorodnii]

zzag added inline comments.

INLINE COMMENTS

> apol wrote in surface_interface.cpp:333
> Using != would probably be more readable and accurate (we're don't need it to 
> be bitwise, we're assuming bool changes it to 1 or 0).

We can't use != because mapped() will be emitted each time a new buffer is 
attached to the surface.

REPOSITORY
  R127 KWayland

BRANCH
  introduce-mapped-signal

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

To: zzag, #kwin, davidedmundson
Cc: apol, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29256: [server] Introduce mapped() signal

[Aleix Pol Gonzalez]

apol added inline comments.

INLINE COMMENTS

> zzag wrote in surface_interface.cpp:333
> We can't use != because mapped() will be emitted each time a new buffer is 
> attached to the surface.

I don't understand, ^ and != are logically equivalent, ^ is the bitwise 
counterpart.

Am I missing something?

REPOSITORY
  R127 KWayland

BRANCH
  introduce-mapped-signal

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

To: zzag, #kwin, davidedmundson
Cc: apol, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29256: [server] Introduce mapped() signal

[Vlad Zahorodnii]

zzag updated this revision to Diff 81456.
zzag marked 2 inline comments as done.
zzag added a comment.


  Use !=

REPOSITORY
  R127 KWayland

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29256?vs=81453&id=81456

BRANCH
  introduce-mapped-signal

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

AFFECTED FILES
  autotests/client/test_wayland_surface.cpp
  src/server/surface_interface.cpp
  src/server/surface_interface.h

To: zzag, #kwin, davidedmundson
Cc: apol, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29256: [server] Introduce mapped() signal

[Vlad Zahorodnii]

zzag added inline comments.

INLINE COMMENTS

> apol wrote in surface_interface.cpp:333
> I don't understand, ^ and != are logically equivalent, ^ is the bitwise 
> counterpart.
> 
> Am I missing something?

Oh, I thought you suggested to do `source->buffer != target->buffer`.

REPOSITORY
  R127 KWayland

BRANCH
  introduce-mapped-signal

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

To: zzag, #kwin, davidedmundson
Cc: apol, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29256: [server] Introduce mapped() signal

[Vlad Zahorodnii]

zzag marked an inline comment as done.

REPOSITORY
  R127 KWayland

BRANCH
  introduce-mapped-signal

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

To: zzag, #kwin, davidedmundson
Cc: apol, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29101: KNewStuff: Fix file path and process call

[Alexander Lohnau]

alex updated this revision to Diff 81467.
alex added a comment.


  Get program in exclusive line
  
  And should this go to release/20.04?

REPOSITORY
  R304 KNewStuff

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29101?vs=81062&id=81467

BRANCH
  arcpatch-D29101

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

AFFECTED FILES
  src/core/installation.cpp

To: alex, #knewstuff, ngraham, nicolasfella, elvisangelaccio, meven, mlaurent, 
leinir
Cc: anthonyfieroni, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, 
bruns

KDE CI: Frameworks » kirigami » kf5-qt5 FreeBSDQt5.14 - Build # 54 - Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks/job/kirigami/job/kf5-qt5%20FreeBSDQt5.14/54/
 Project:
kf5-qt5 FreeBSDQt5.14
 Date of build:
Tue, 28 Apr 2020 19:35:57 +
 Build duration:
1 min 25 sec and counting
   JUnit Tests
  Name: projectroot.usr.home.jenkins.workspace.Frameworks.kirigami.kf5-qt5_FreeBSDQt514 Failed: 2 test(s), Passed: 5 test(s), Skipped: 0 test(s), Total: 7 test(s)Failed: projectroot.usr.home.jenkins.workspace.Frameworks.kirigami.kf5-qt5_FreeBSDQt514.autotests.tst_keynavigation.qmlFailed: projectroot.usr.home.jenkins.workspace.Frameworks.kirigami.kf5-qt5_FreeBSDQt514.autotests.tst_listskeynavigation.qml

D29153: Move handling of untrusted programs to ApplicationLauncherJob.

[David Faure]

dfaure added inline comments.

INLINE COMMENTS

> broulik wrote in applicationlauncherjob.cpp:155
> With this it starts to look as hard to follow as KRun :)

Not even close :-)

(OpenUrlJob will be more complicated, somewhere in between this one and KRun...)

REPOSITORY
  R241 KIO

BRANCH
  2020_04_UntrustedProgramHandler

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

To: dfaure, ahmadsamir, broulik, ngraham, mdlubakowski
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29153: Move handling of untrusted programs to ApplicationLauncherJob.

[David Faure]

This revision was automatically updated to reflect the committed changes.
Closed by commit R241:f0ae038490e6: Move handling of untrusted programs to 
ApplicationLauncherJob. (authored by dfaure).

REPOSITORY
  R241 KIO

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29153?vs=81173&id=81472

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

AFFECTED FILES
  autotests/applicationlauncherjobtest.cpp
  autotests/applicationlauncherjobtest.h
  src/core/CMakeLists.txt
  src/core/jobuidelegateextension.h
  src/core/untrustedprogramhandlerinterface.cpp
  src/core/untrustedprogramhandlerinterface.h
  src/gui/applicationlauncherjob.cpp
  src/gui/applicationlauncherjob.h
  src/widgets/CMakeLists.txt
  src/widgets/jobuidelegate.cpp
  src/widgets/krun.cpp
  src/widgets/krun_p.h
  src/widgets/widgetsuntrustedprogramhandler.cpp
  src/widgets/widgetsuntrustedprogramhandler.h
  tests/kruntest.cpp

To: dfaure, ahmadsamir, broulik, ngraham, mdlubakowski
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29251: API dox: use ulong typedef with Q_PROPERTY(percent) to avoid doxygen bug

[David Faure]

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


  Yes indeed, for sure "int" would be enough.

REPOSITORY
  R244 KCoreAddons

BRANCH
  fixkjobpercentdocs

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

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

KDE CI: Frameworks » kio » kf5-qt5 FreeBSDQt5.14 - Build # 79 - Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks/job/kio/job/kf5-qt5%20FreeBSDQt5.14/79/
 Project:
kf5-qt5 FreeBSDQt5.14
 Date of build:
Tue, 28 Apr 2020 19:44:57 +
 Build duration:
6 min 4 sec and counting
   JUnit Tests
  Name: projectroot Failed: 1 test(s), Passed: 51 test(s), Skipped: 0 test(s), Total: 52 test(s)Failed: projectroot.autotests.kiocore_jobtestName: projectroot.autotests Failed: 0 test(s), Passed: 6 test(s), Skipped: 0 test(s), Total: 6 test(s)Name: projectroot.src.ioslaves.trash Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)Name: projectroot.src.kpasswdserver Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)

D29251: API dox: use ulong typedef with Q_PROPERTY(percent) to avoid doxygen bug

[Friedrich W. H. Kossebau]

This revision was automatically updated to reflect the committed changes.
Closed by commit R244:9e76c0bbdec4: API dox: use ulong typedef with 
Q_PROPERTY(percent) to avoid doxygen bug (authored by kossebau).

REPOSITORY
  R244 KCoreAddons

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29251?vs=81425&id=81473

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

AFFECTED FILES
  src/lib/jobs/kjob.h

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

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

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks/job/kcoreaddons/job/kf5-qt5%20FreeBSDQt5.14/13/
 Project:
kf5-qt5 FreeBSDQt5.14
 Date of build:
Tue, 28 Apr 2020 19:55:25 +
 Build duration:
1 min 44 sec and counting
   JUnit Tests
  Name: projectroot Failed: 2 test(s), Passed: 25 test(s), Skipped: 0 test(s), Total: 27 test(s)Failed: projectroot.autotests.kdirwatch_inotify_unittestFailed: projectroot.autotests.klistopenfilesjobtest_unix

D29269: Consistently use knotify-config.h to pass in flags about Canberra/Phonon

[Friedrich W. H. Kossebau]

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

REPOSITORY
  R305 KNotifyConfig

BRANCH
  useconsistentlyconfigfile

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

AFFECTED FILES
  CMakeLists.txt
  src/CMakeLists.txt
  src/knotify-config.h.cmake
  src/knotifyconfigactionswidget.cpp
  src/knotifyconfigactionswidget.h

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

D29269: Consistently use knotify-config.h to pass in flags about Canberra/Phonon

[Friedrich W. H. Kossebau]

kossebau updated this revision to Diff 81475.
kossebau added a comment.


  use consistently Canberra_FOUND

REPOSITORY
  R305 KNotifyConfig

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29269?vs=81474&id=81475

BRANCH
  useconsistentlyconfigfile

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

AFFECTED FILES
  CMakeLists.txt
  src/CMakeLists.txt
  src/knotify-config.h.cmake
  src/knotifyconfigactionswidget.cpp
  src/knotifyconfigactionswidget.h

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

D29251: API dox: use ulong typedef with Q_PROPERTY(percent) to avoid doxygen bug

[Friedrich W. H. Kossebau]

kossebau added a comment.


  In D29251#659376 , @dfaure wrote:
  
  > Yes indeed, for sure "int" would be enough.
  
  
  So okay if I add a  "// KF6 TODO: make int" behind the Q_PROPERTY(percent) at 
the end of the line?

REPOSITORY
  R244 KCoreAddons

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

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

D29123: Do not mark entry as uninstalled if uninstallation script failed

[Alexander Lohnau]

alex updated this revision to Diff 81476.
alex added a comment.


  Display more technical information in error message

REPOSITORY
  R304 KNewStuff

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29123?vs=81076&id=81476

BRANCH
  arcpatch-D29123

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

AFFECTED FILES
  src/core/engine.cpp
  src/core/installation.cpp
  src/core/installation.h

To: alex, #knewstuff, meven, ngraham, leinir
Cc: leinir, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29079: android: include the architecture on the apk name

[Nicolas Fella]

nicolasfella 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/D29079

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

D24477: Add PATH/LD_LIBRARY_PATH to qrcAlias invocation

[Friedrich W. H. Kossebau]

kossebau added inline comments.

INLINE COMMENTS

> kossebau wrote in CMakeLists.txt:56
> This breaks builds with CMake 3.5 - 3.7, as `$` was only added for CMake 
> 3.8.
> 
> See what the official minimum required CMake version 3.5 allows here:
> https://cmake.org/cmake/help/v3.5/manual/cmake-generator-expressions.7.html

Fixed with 95a64300d654fb88352e0008854c5522df769d3c 


REPOSITORY
  R266 Breeze Icons

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

To: masonm, #vdg, ndavis
Cc: kossebau, ltoscano, kde-frameworks-devel, #vdg, LeGast00n, cblack, 
michaelh, ngraham, bruns

D29269: Consistently use knotify-config.h to pass in flags about Canberra/Phonon

[Nicolas Fella]

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

REPOSITORY
  R305 KNotifyConfig

BRANCH
  useconsistentlyconfigfile

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

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

D29269: Consistently use knotify-config.h to pass in flags about Canberra/Phonon

[Friedrich W. H. Kossebau]

This revision was automatically updated to reflect the committed changes.
Closed by commit R305:e2a22b0f0c62: Consistently use knotify-config.h to pass 
in flags about Canberra/Phonon (authored by kossebau).

REPOSITORY
  R305 KNotifyConfig

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29269?vs=81475&id=81479

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

AFFECTED FILES
  CMakeLists.txt
  src/CMakeLists.txt
  src/knotify-config.h.cmake
  src/knotifyconfigactionswidget.cpp
  src/knotifyconfigactionswidget.h

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

KDE CI: Frameworks » kcoreaddons » kf5-qt5 FreeBSDQt5.14 - Build # 14 - Still Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks/job/kcoreaddons/job/kf5-qt5%20FreeBSDQt5.14/14/
 Project:
kf5-qt5 FreeBSDQt5.14
 Date of build:
Tue, 28 Apr 2020 21:26:13 +
 Build duration:
2 min 8 sec and counting
   JUnit Tests
  Name: projectroot Failed: 2 test(s), Passed: 25 test(s), Skipped: 0 test(s), Total: 27 test(s)Failed: projectroot.autotests.kdirwatch_inotify_unittestFailed: projectroot.autotests.klistopenfilesjobtest_unix

KDE CI: Frameworks » kcoreaddons » kf5-qt5 SUSEQt5.12 - Build # 187 - Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks/job/kcoreaddons/job/kf5-qt5%20SUSEQt5.12/187/
 Project:
kf5-qt5 SUSEQt5.12
 Date of build:
Tue, 28 Apr 2020 21:26:13 +
 Build duration:
4 min 23 sec and counting
   BUILD ARTIFACTS
  abi-compatibility-results.yamlacc/KF5CoreAddons-5.70.0.xmlcompat_reports/KF5CoreAddons_compat_report.htmllogs/KF5CoreAddons/5.70.0/log.txt
   JUnit Tests
  Name: (root) Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)Name: projectroot Failed: 1 test(s), Passed: 26 test(s), Skipped: 0 test(s), Total: 27 test(s)Failed: projectroot.autotests.kdirwatch_qfswatch_unittest
   Cobertura Report
  
   Project Coverage Summary
  
   Name
  PackagesFilesClassesLinesConditionalsCobertura Coverage Report91%
(10/11)86%
(80/93)86%
(80/93)76%
(6934/9127)43%
(10807/24863)Coverage Breakdown by Package
Name
   FilesClassesLinesConditionalsautotests94%
(31/33)94%
(31/33)97%
(2902/2996)49%
(6201/12736)src.desktoptojson100%
(2/2)100%
(2/2)78%
(90/115)37%
(108/290)src.lib67%
(2/3)67%
(2/3)62%
(382/621)26%
(244/924)src.lib.caching100%
(2/2)100%
(2/2)45%
(352/782)18%
(187/1054)src.lib.io75%
(9/12)75%
(9/12)66%
(869/1309)35%
(991/2822)src.lib.jobs71%
(5/7)71%
(5/7)55%
(157/284)39%
(54/140)src.lib.plugin100%
(7/7)100%
(7/7)85%
(681/801)42%
(957/2273)src.lib.randomness100%
(2/2)100%
(2/2)69%
(66/95)58%
(45/78)src.lib.text63%
(5/8)63%
(5/8)52%
(441/848)47%
(1008/2157)src.lib.util100%
(15/15)100%
(15/15)83%
(994/1191)51%
(1012/1999)tests0%
(0/2)0%
(0/2)0%
(0/85)0%
(0/390)

KDE CI: Frameworks » kcoreaddons » kf5-qt5 SUSEQt5.14 - Build # 15 - Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks/job/kcoreaddons/job/kf5-qt5%20SUSEQt5.14/15/
 Project:
kf5-qt5 SUSEQt5.14
 Date of build:
Tue, 28 Apr 2020 21:26:13 +
 Build duration:
4 min 30 sec and counting
   BUILD ARTIFACTS
  abi-compatibility-results.yamlacc/KF5CoreAddons-5.70.0.xmlcompat_reports/KF5CoreAddons_compat_report.htmllogs/KF5CoreAddons/5.70.0/log.txt
   JUnit Tests
  Name: (root) Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)Name: projectroot Failed: 1 test(s), Passed: 26 test(s), Skipped: 0 test(s), Total: 27 test(s)Failed: projectroot.autotests.kdirwatch_qfswatch_unittest
   Cobertura Report
  
   Project Coverage Summary
  
   Name
  PackagesFilesClassesLinesConditionalsCobertura Coverage Report91%
(10/11)86%
(80/93)86%
(80/93)76%
(6934/9126)43%
(10805/24857)Coverage Breakdown by Package
Name
   FilesClassesLinesConditionalsautotests94%
(31/33)94%
(31/33)97%
(2902/2996)49%
(6200/12734)src.desktoptojson100%
(2/2)100%
(2/2)78%
(90/115)37%
(108/290)src.lib67%
(2/3)67%
(2/3)62%
(382/621)26%
(244/924)src.lib.caching100%
(2/2)100%
(2/2)45%
(352/782)18%
(187/1054)src.lib.io75%
(9/12)75%
(9/12)66%
(869/1309)35%
(991/2822)src.lib.jobs71%
(5/7)71%
(5/7)55%
(157/284)39%
(54/140)src.lib.plugin100%
(7/7)100%
(7/7)85%
(681/800)42%
(956/2269)src.lib.randomness100%
(2/2)100%
(2/2)69%
(66/95)58%
(45/78)src.lib.text63%
(5/8)63%
(5/8)52%
(441/848)47%
(1008/2157)src.lib.util100%
(15/15)100%
(15/15)83%
(994/1191)51%
(1012/1999)tests0%
(0/2)0%
(0/2)0%
(0/85)0%
(0/390)

D29258: Don't use notifybysnore.h on MSYS2

[Piyush Aggarwal]

brute4s99 added a comment.


  > SnoreToast fails to build on MSYS2 due to missing
  >  which apparently is not available for this compiler.
  
  I'm sorry, missing what exactly?

REPOSITORY
  R289 KNotifications

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

To: wojnilowicz, broulik, brute4s99
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D22554: Finer No-Dbus on Windows

[Piyush Aggarwal]

brute4s99 added a comment.


  closing this diff.

REPOSITORY
  R289 KNotifications

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

To: brute4s99, nicolasfella, broulik
Cc: andriusr, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D22554: Finer No-Dbus on Windows

[Piyush Aggarwal]

brute4s99 abandoned this revision.

REPOSITORY
  R289 KNotifications

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

To: brute4s99, nicolasfella, broulik
Cc: andriusr, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29258: Don't use notifybysnore.h on MSYS2

[Hannah von Reth]

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


  Well the code is header only, so gcc can use it too.
  Everything needed is to pull in a binary, that's not ideal but I guess its 
better than no notifications on Windows.

REPOSITORY
  R289 KNotifications

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

To: wojnilowicz, broulik, brute4s99, vonreth
Cc: vonreth, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29079: android: include the architecture on the apk name

[Aleix Pol Gonzalez]

This revision was automatically updated to reflect the committed changes.
Closed by commit R240:fca97c036c8d: android: include the architecture on the 
apk name (authored by apol).

REPOSITORY
  R240 Extra CMake Modules

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29079?vs=80829&id=81480

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

AFFECTED FILES
  toolchain/ECMAndroidDeployQt.cmake

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