D29231: [WIP] Add keyboard_shortcuts_inhibit protocol

[Vlad Zahorodnii]

zzag added a comment.


  Thanks, this patch looks good to me. Although it would be nice to see the 
kwin side before leaving a +1. :)

REPOSITORY
  R127 KWayland

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

To: bport, zzag, davidedmundson, apol
Cc: romangg, crossi, kde-frameworks-devel, LeGast00n, cblack, michaelh, 
ngraham, bruns

D28882: Create protocol to manage video feeds

[Vlad Zahorodnii]

zzag added a comment.


  In D28882#658780 , @apol wrote:
  
  > > In future, it might be faster to put up just the interface xml for review 
first.
  >
  > @davidedmundson  @zzag I don't really see how it would have made a 
difference, you only decided to review it 7 to 10 days after I first submitted 
it. 路
  >
  > > What about using existing wl_output objects? The add_source event can be 
simplified quite a lot (even maybe dropped). For windows, we could use string 
handles.
  >
  > So your proposal would be to pass a random resource id or string and see 
what the compositor spits back?
  
  
  Well, it's not that different from passsing uints like this patch proposes. 
In either case we have to have some protection against garbage input values and 
possibly inert resources. wl_outputs are not some random objects and 
practically every GUI application keeps track of them.
  
  > My intention was to keep the protocol auto-contained to some extent so 
every client doesn't need to track windows and screens to be able to request a 
stream.

REPOSITORY
  R127 KWayland

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

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

Re: Information regarding upcoming Gitlab Migration

[Bhushan Shah]

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
wanted to work on "something" so I did literally browse through various
repositories to find something where my technical capabilities were
enough to work on [1]. Back then it was projects.kde.org (chiliproject
installation).

[1] https://blog.bshah.in/2013/09/01/hello-planet/

-- 
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

Re: Information regarding upcoming Gitlab Migration

[Bhushan Shah]

Hi Ingo,

On Mon, Apr 27, 2020 at 03:46:13PM +0200, Ingo Klöcker wrote:
> > > I'm sorry, but I don't think that this is solved by your proposal for the
> > > KDE PIM projects because not everything related to KDE PIM (e.g. relevant
> > > frameworks like kcontacts, kholidays, kpeople and soon kdav) will be in
> > > the same group. The same is true for any project which uses some
> > > frameworks, e.g. graphics and the imageformats framework or whatever
> > > group kate and kwrite are going to end up in and the ktexteditor
> > > framework.
> > 
> > This is something which can be easily solved by Gitlab, Gitlab offers a
> > solution where project can be shared with another group.
> > 
> > So e.g. sharing kcontacts with kdepim should be possible, then all merge
> > requests/issues from kcontacts would show up under pim as well.
> 
> Great. So we could put all repos into an "all" group (e.g. rename kde to all) 
> and then have every subcommunity decide for themselves which repos they want 
> to see in their group.

No, sadly this does not work, I just tested this,

I have two different groups here

- https://invent.kde.org/sysadmin/test/test1
- https://invent.kde.org/sysadmin/test/test2

test1 have a repo called foo under it, which is shared with the test2
group. When someone visits test2, they are not offered the list of the
shared repositories but they are instead offered the empty page. One
have to click on Shared repositories tab to actually see the list.

https://invent.kde.org/groups/sysadmin/test/test2/-/shared

This defeats the purpose of the creating subgroups (offering easy
reachability).

-- 
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

Re: Information regarding upcoming Gitlab Migration

[Bhushan Shah]

Hi Nate,

On Mon, Apr 27, 2020 at 07:45:23AM -0600, Nate Graham wrote:
> Trying to categorize everything into a single group cannot succeed because
> many projects could logically belong to multiple groups (e.g
> plasma-framework is a framework that's a part of Plasma; Discover is an app
> that's a part of Plasma; kdenetwork-filesharing and kio-extras are libraries
> that are distributed via the apps release service). I foresee endless
> pointless arguments about the best group for something to live in.

I've agreed in previous threads that sometime our grouping is not
perfect, but this is something we can improve instead of throwing idea
of grouping out altogether.

> Let's step back: do we have to put every repo inside a group in the first
> place? Is it solely so you can look at a nice list of all open merge
> requests for PIM/Frameworks/etc? If so, perhaps this workflow could be
> approximated with tags instead or group assignments instead

No goal is not just that you get nice list of all open merge requests or
issues. Main goal is we want to offer user or potential contributors a
list of closely related projects instead of list of all 1100+ projects
we have. That would mean, If user wants to see all frameworks, or
graphics applications, or multimedia applications, they can.

The workflow, with labels you mention is trying to achieve a totally
different goal then what we are trying to solve here. Labels/Tags are
for sorting issues, and/or merge requests. They can't be reliable
solution for the sorting of the multiple repositories.

On technical side, Gitlab does not offer labels for projects, but
setting called topic. You can see that in screenshot[1] linked. Besides,
from home page there's no way to filter something for e.g "Graphics".
nore project listing shows the tags alongside of the project names, also
making use of this tags means that if user clicks this tags, what they
are offered is *all* the repositories including forks of the
repositories, which means when you search for graphics [2], you get many
duplicative results and this is really not something discoverable.

> We create many very granular groups for the purposes of organizing teams and
> and performing code review (e.g. Plasma, KWin, Frameworks, PIM, Krita,
> Dolphin, Okular, VDG, etc.) and then every new merge request could receive a
> tag or assignee corresponding to its relevant code review groups (e.g. merge
> requests for kio and kio-extras could get get tagged with both "Frameworks",
> and "Dolphin"; plasma-frameworks MRs could get tagged with both "Plasma" and
> "Frameworks", and so on).

As explained above, while grouping repositories is trying to solve the
merge requests/issue organization, it is not sole purpose of the
suggested grouping, discoverability and reachability is the main issue
we are trying to solve here.

[1] https://i.imgur.com/h1L1A5H.png
[2] https://i.imgur.com/ajOszEL.png

-- 
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

D29231: [WIP] Add keyboard_shortcuts_inhibit protocol

[Aleix Pol Gonzalez]

apol added inline comments.

INLINE COMMENTS

> keyboard_shortcuts_inhibit_interface.cpp:144
> +QPair key(surface, seat);
> +if (m_inhibitors.contains(key)) {
> +return m_inhibitors[key];

Just `return m_inhibitors.value({ surface, seat })` to save a look-up and a few 
lines of code.

REPOSITORY
  R127 KWayland

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

To: bport, zzag, davidedmundson, apol
Cc: romangg, crossi, kde-frameworks-devel, LeGast00n, cblack, michaelh, 
ngraham, bruns

D28882: Create protocol to manage video feeds

[Aleix Pol Gonzalez]

apol added a comment.


  > In future, it might be faster to put up just the interface xml for review 
first.
  
  @davidedmundson  @zzag I don't really see how it would have made a 
difference, you only decided to review it 7 to 10 days after I first submitted 
it. 路
  
  > What about using existing wl_output objects? The add_source event can be 
simplified quite a lot (even maybe dropped). For windows, we could use string 
handles.
  
  So your proposal would be to pass a random resource id or string and see what 
the compositor spits back?
  My intention was to keep the protocol auto-contained to some extent so every 
client doesn't need to track windows and screens to be able to request a stream.

REPOSITORY
  R127 KWayland

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

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

D29231: [WIP] Add keyboard_shortcuts_inhibit protocol

[Benjamin Port]

bport updated this revision to Diff 81386.
bport added a comment.


  fix qobject macro indentation

REPOSITORY
  R127 KWayland

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29231?vs=81385=81386

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

AFFECTED FILES
  autotests/server/CMakeLists.txt
  autotests/server/test_keyboard_shortcuts_inhibitor_interface.cpp
  src/server/CMakeLists.txt
  src/server/display.cpp
  src/server/display.h
  src/server/keyboard_shortcuts_inhibit_interface.cpp
  src/server/keyboard_shortcuts_inhibit_interface.h

To: bport, zzag, davidedmundson, apol
Cc: romangg, crossi, kde-frameworks-devel, LeGast00n, cblack, michaelh, 
ngraham, bruns

D29231: [WIP] Add keyboard_shortcuts_inhibit protocol

[Benjamin Port]

bport updated this revision to Diff 81385.
bport added a comment.


  fix test, and take in consideration zzag feedback

REPOSITORY
  R127 KWayland

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29231?vs=81361=81385

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

AFFECTED FILES
  autotests/server/CMakeLists.txt
  autotests/server/test_keyboard_shortcuts_inhibitor_interface.cpp
  src/server/CMakeLists.txt
  src/server/display.cpp
  src/server/display.h
  src/server/keyboard_shortcuts_inhibit_interface.cpp
  src/server/keyboard_shortcuts_inhibit_interface.h

To: bport, zzag, davidedmundson, apol
Cc: romangg, crossi, kde-frameworks-devel, LeGast00n, cblack, michaelh, 
ngraham, bruns

D29153: Move handling of untrusted programs to ApplicationLauncherJob.

[David Faure]

dfaure added a comment.


  @broulik ping?

REPOSITORY
  R241 KIO

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

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

D29206: Move check for invalid service from KDesktopFileActions to ApplicationLauncherJob

[David Faure]

dfaure closed this revision.

REPOSITORY
  R241 KIO

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

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

D29206: Move check for invalid service from KDesktopFileActions to ApplicationLauncherJob

[Ahmad Samir]

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

INLINE COMMENTS

> dfaure wrote in kprocessrunner.cpp:55
> I see what you're saying.
> 
> It's the name of the spec, though.
> https://specifications.freedesktop.org/desktop-entry-spec/latest/
> 
> Each file is an "entry for the desktop", I guess.

Well, what can we do... that ship has sailed.

REPOSITORY
  R241 KIO

BRANCH
  2020_04_invalid_service

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

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

D29170: Detect executables without +x permission in $PATH to improve error message

[David Faure]

dfaure closed this revision.

REPOSITORY
  R241 KIO

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

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

D29239: [KPlotting] foreach is gone, build with -DQT_NO_FOREACH

[Ahmad Samir]

This revision was automatically updated to reflect the committed changes.
Closed by commit R277:a6c269a6b2ce: [KPlotting] foreach is gone, build with 
-DQT_NO_FOREACH (authored by ahmadsamir).

REPOSITORY
  R277 KPlotting

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29239?vs=81381=81383

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

AFFECTED FILES
  CMakeLists.txt

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

D29239: [KPlotting] foreach is gone, build with -DQT_NO_FOREACH

[David Faure]

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

REPOSITORY
  R277 KPlotting

BRANCH
  l-no-foreach (branched from master)

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

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

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

[Noah Davis]

ndavis added inline comments.

INLINE COMMENTS

> davidre wrote in kcolorscheme.cpp:271
> I would have expected at least of one the new colors to have the same value 
> as this one.

Why is that? The only one that might is Active, but that's not really used much 
right now.

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

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

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks/job/solid/job/kf5-qt5%20FreeBSDQt5.14/14/
 Project:
kf5-qt5 FreeBSDQt5.14
 Date of build:
Mon, 27 Apr 2020 21:07:57 +
 Build duration:
2 min 0 sec and counting
   JUnit Tests
  Name: projectroot Failed: 1 test(s), Passed: 3 test(s), Skipped: 0 test(s), Total: 4 test(s)Failed: projectroot.autotests.halbasictest

D29233: [Solid] Port foreach to range/index for

[Ahmad Samir]

This revision was automatically updated to reflect the committed changes.
Closed by commit R245:dd878b1c2933: [Solid] Port foreach to range/index for 
(authored by ahmadsamir).

REPOSITORY
  R245 Solid

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29233?vs=81359=81382

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

AFFECTED FILES
  src/solid/devices/backends/upower/upowermanager.cpp
  src/solid/devices/backends/win/winblock.cpp
  src/solid/devices/backends/win/windevicemanager.cpp
  src/solid/devices/backends/win/winopticaldrive.cpp
  src/solid/devices/backends/win/winprocessor.cpp
  src/tools/solid-hardware/solid-hardware.cpp

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

D29239: [KPlotting] foreach is gone, build with -DQT_NO_FOREACH

[Ahmad Samir]

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

TEST PLAN
  make && ctest

REPOSITORY
  R277 KPlotting

BRANCH
  l-no-foreach (branched from master)

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

AFFECTED FILES
  CMakeLists.txt

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

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

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks/job/solid/job/kf5-qt5%20FreeBSDQt5.14/13/
 Project:
kf5-qt5 FreeBSDQt5.14
 Date of build:
Mon, 27 Apr 2020 21:00:42 +
 Build duration:
2 min 1 sec and counting
   JUnit Tests
  Name: projectroot Failed: 1 test(s), Passed: 3 test(s), Skipped: 0 test(s), Total: 4 test(s)Failed: projectroot.autotests.halbasictest

D29229: [KPlotting] Port foreach (deprecated) to range for

[Ahmad Samir]

This revision was automatically updated to reflect the committed changes.
Closed by commit R277:8281cb629ffa: [KPlotting] Port foreach (deprecated) to 
range for (authored by ahmadsamir).

REPOSITORY
  R277 KPlotting

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29229?vs=81339=81380

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

AFFECTED FILES
  src/kplotobject.cpp
  src/kplotwidget.cpp

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

D29221: [FakeCdrom] Add a new UnknownMediumType enumerator to MediumType

[Ahmad Samir]

This revision was automatically updated to reflect the committed changes.
Closed by commit R245:c4e8755ac324: [FakeCdrom] Add a new UnknownMediumType 
enumerator to MediumType (authored by ahmadsamir).

REPOSITORY
  R245 Solid

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29221?vs=81316=81379

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

AFFECTED FILES
  src/solid/devices/backends/fakehw/fakecdrom.cpp
  src/solid/devices/frontend/opticaldrive.h

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

Re: Information regarding upcoming Gitlab Migration

[Olivier Churlaud]

Le 27 avril 2020 22:33:12 GMT+02:00, Ben Cooksley  a écrit :
>On Tue, Apr 28, 2020 at 8:31 AM Albert Astals Cid 
>wrote:
>>
>> El dilluns, 27 d’abril de 2020, a les 13:19:07 CEST, Ben Cooksley va
>escriure:
>> > On Mon, Apr 27, 2020 at 11:12 PM Olivier Churlaud
> wrote:
>> > >
>> > > Hi,
>> > >
>> > > Le lundi 27 avril 2020, 12:38:42 CEST Aleix Pol a écrit :
>> > > > On Mon, Apr 27, 2020 at 3:41 AM 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
>> > > > >
>> > >
>> > > Thank you for having options and talking to us before
>implementing it.
>> > >
>> > > > > 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
>> > > >
>> > > > 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.
>> > > >
>> > > > e.g. Is okular graphics or office? Is gwenview plasma or
>graphics? Is
>> > > > krita graphics or its own thing?
>> > > >
>> > > > I really prefer when I don't have to guess this kind of things
>when
>> > > > fetching a repository.
>> > > >
>> > >
>> > > I 100% agree with Aleix and I think it would also be detrimental
>for discoverability, exactly for the examples Aleix just gave.
>> > >
>> > > We came back from this subgroups ideas some times ago : wiki
>pages were hard to find because hidden under layers of groups. The same
>was true for api documentations. Now everything is flat and I think
>it's easier to find.
>> > >
>> > > Another bad message could also be sent by this: instead of
>exposing Konsole or Ark as two applications under the KDE umbrella, it
>would look like Utils for KDE, bringing back the KDE Desktop idea
>(where every application is already store in a submenu).
>> > >
>> > > As someone wrote later, if I'm looking for a given application,
>there is always the search function...
>> >
>> > That requires that you know it exists. We have 1,043 mainline
>> > repositories at the moment, which translates to 53 pages of
>projects
>> > under a flat structure system.
>> > Reality is nobody is going to page through that looking for
>something.
>>
>> But they have gitlab search, don't they?
>
>They do yes.
>
>>
>> I mean it's the solution you told Aleix to figure out if Okular was
>inside graphics or okular.
>>
>> Why is search valid for one case and not for the other?
>
>Because in order to search for something, 

Re: Information regarding upcoming Gitlab Migration

[Albert Astals Cid]

El dilluns, 27 d’abril de 2020, a les 3:40:01 CEST, Bhushan Shah va escriure:
> [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.

Anything that breaks kde:$repo will break the release-tools used for the 
monthly releases done by the release service and the l10n scripty scripts.

If it ends up happening it would be good if such change is as far away as 
possible from a release so the scripts can be adapted timely and hopefully 
without mistakes.

Cheers,
  Albert

> 
> Thanks!
> Bhushan for sysadmin team
> 
> [1] 
> https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent
> 
> 

D28802: Add standard shortcut for "Show/Hide Hidden Files"

[Nathaniel Graham]

ngraham added a dependent revision: D29238: Use Standard "Show/Hide Hidden 
files" shortcuts in directory chooser dialog.

REPOSITORY
  R237 KConfig

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

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

D29238: Use Standard "Show/Hide Hidden files" shortcuts in directory chooser dialog

[Nathaniel Graham]

ngraham created this revision.
ngraham added reviewers: Plasma, Frameworks.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
ngraham requested review of this revision.

REVISION SUMMARY
  New standard shortcuts were added in D28802 
 and adopting them replaces the fairly 
random
  F8 shortcut here.
  
  CCBUG: 262551
  
  Depends on D28802 

TEST PLAN
  Open directory chooser dialog from the Add Folder button in the plasma 
slideshow
  wallpaper dialog and hit Ctrl+H or Alt+.

REPOSITORY
  R135 Integration for Qt applications in Plasma

BRANCH
  use-standard-show-hide-files-shortcuts (branched from master)

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

AFFECTED FILES
  CMakeLists.txt
  src/platformtheme/kdirselectdialog.cpp

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

Re: Information regarding upcoming Gitlab Migration

[Ben Cooksley]

On Tue, Apr 28, 2020 at 8:31 AM Albert Astals Cid  wrote:
>
> El dilluns, 27 d’abril de 2020, a les 13:19:07 CEST, Ben Cooksley va escriure:
> > On Mon, Apr 27, 2020 at 11:12 PM Olivier Churlaud  
> > wrote:
> > >
> > > Hi,
> > >
> > > Le lundi 27 avril 2020, 12:38:42 CEST Aleix Pol a écrit :
> > > > On Mon, Apr 27, 2020 at 3:41 AM 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
> > > > >
> > >
> > > Thank you for having options and talking to us before implementing it.
> > >
> > > > > 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
> > > >
> > > > 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.
> > > >
> > > > e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is
> > > > krita graphics or its own thing?
> > > >
> > > > I really prefer when I don't have to guess this kind of things when
> > > > fetching a repository.
> > > >
> > >
> > > I 100% agree with Aleix and I think it would also be detrimental for 
> > > discoverability, exactly for the examples Aleix just gave.
> > >
> > > We came back from this subgroups ideas some times ago : wiki pages were 
> > > hard to find because hidden under layers of groups. The same was true for 
> > > api documentations. Now everything is flat and I think it's easier to 
> > > find.
> > >
> > > Another bad message could also be sent by this: instead of exposing 
> > > Konsole or Ark as two applications under the KDE umbrella, it would look 
> > > like Utils for KDE, bringing back the KDE Desktop idea (where every 
> > > application is already store in a submenu).
> > >
> > > As someone wrote later, if I'm looking for a given application, there is 
> > > always the search function...
> >
> > That requires that you know it exists. We have 1,043 mainline
> > repositories at the moment, which translates to 53 pages of projects
> > under a flat structure system.
> > Reality is nobody is going to page through that looking for something.
>
> But they have gitlab search, don't they?

They do yes.

>
> I mean it's the solution you told Aleix to figure out if Okular was inside 
> graphics or okular.
>
> Why is search valid for one case and not for the other?

Because in order to search for something, you need to know it exists.

If you are just casually browsing, then the search can't 

Re: Information regarding upcoming Gitlab Migration

[Albert Astals Cid]

El dilluns, 27 d’abril de 2020, a les 13:19:07 CEST, Ben Cooksley va escriure:
> On Mon, Apr 27, 2020 at 11:12 PM Olivier Churlaud  
> wrote:
> >
> > Hi,
> >
> > Le lundi 27 avril 2020, 12:38:42 CEST Aleix Pol a écrit :
> > > On Mon, Apr 27, 2020 at 3:41 AM 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
> > > >
> >
> > Thank you for having options and talking to us before implementing it.
> >
> > > > 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
> > >
> > > 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.
> > >
> > > e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is
> > > krita graphics or its own thing?
> > >
> > > I really prefer when I don't have to guess this kind of things when
> > > fetching a repository.
> > >
> >
> > I 100% agree with Aleix and I think it would also be detrimental for 
> > discoverability, exactly for the examples Aleix just gave.
> >
> > We came back from this subgroups ideas some times ago : wiki pages were 
> > hard to find because hidden under layers of groups. The same was true for 
> > api documentations. Now everything is flat and I think it's easier to find.
> >
> > Another bad message could also be sent by this: instead of exposing Konsole 
> > or Ark as two applications under the KDE umbrella, it would look like Utils 
> > for KDE, bringing back the KDE Desktop idea (where every application is 
> > already store in a submenu).
> >
> > As someone wrote later, if I'm looking for a given application, there is 
> > always the search function...
> 
> That requires that you know it exists. We have 1,043 mainline
> repositories at the moment, which translates to 53 pages of projects
> under a flat structure system.
> Reality is nobody is going to page through that looking for something.

But they have gitlab search, don't they?

I mean it's the solution you told Aleix to figure out if Okular was inside 
graphics or okular.

Why is search valid for one case and not for the other?

Cheers,
  Albert

> 
> Please also see my point regarding listing merge requests at the group
> level - you can see an example of what a flat structure ends up
> looking like at https://gitlab.gnome.org/GNOME
> 
> For those projects that span multiple repositories, you have just
> denied them any chance or ability to see a listing of everything
> related to their wider project.
> 
> >
> > Best regards,
> > Olivier
> > > Aleix
> >
> >
> 
> Cheers,
> 

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

[David Redondo]

davidre added inline comments.

INLINE COMMENTS

> kcolorscheme.cpp:271
>  static const DecoDefaultColors defaultDecorationColors = {
>  {  61, 174, 233 }, // Focus
>  { 147, 206, 233 }, // Hover

I would have expected at least of one the new colors to have the same value as 
this one.

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

Re: Information regarding upcoming Gitlab Migration

[Albert Astals Cid]

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

KDE CI: Frameworks » kio » kf5-qt5 FreeBSDQt5.14 - Build # 76 - Fixed!

[CI System]

BUILD SUCCESS
 Build URL
https://build.kde.org/job/Frameworks/job/kio/job/kf5-qt5%20FreeBSDQt5.14/76/
 Project:
kf5-qt5 FreeBSDQt5.14
 Date of build:
Mon, 27 Apr 2020 19:45:51 +
 Build duration:
6 min 49 sec and counting
   JUnit Tests
  Name: projectroot Failed: 0 test(s), Passed: 52 test(s), Skipped: 0 test(s), Total: 52 test(s)Name: 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)

KDE CI: Frameworks » kio » kf5-qt5 SUSEQt5.14 - Build # 68 - Fixed!

[CI System]

BUILD SUCCESS
 Build URL
https://build.kde.org/job/Frameworks/job/kio/job/kf5-qt5%20SUSEQt5.14/68/
 Project:
kf5-qt5 SUSEQt5.14
 Date of build:
Mon, 27 Apr 2020 19:45:51 +
 Build duration:
6 min 23 sec and counting
   BUILD ARTIFACTS
  acc/KF5KIO-5.70.0.xmllogs/KF5KIO/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: 0 test(s), Passed: 53 test(s), Skipped: 0 test(s), Total: 53 test(s)Name: projectroot.autotests Failed: 0 test(s), Passed: 6 test(s), Skipped: 0 test(s), Total: 6 test(s)Name: projectroot.src.ioslaves.trash Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)Name: projectroot.src.kpasswdserver Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)
   Cobertura Report
  
   Project Coverage Summary
  
   Name
  PackagesFilesClassesLinesConditionalsCobertura Coverage Report67%
(24/36)67%
(270/406)67%
(270/406)56%
(34939/62173)40%
(17735/43930)Coverage Breakdown by Package
Name
   FilesClassesLinesConditionalsautotests100%
(58/58)100%
(58/58)95%
(9812/10281)46%
(4580/9884)autotests.http100%
(5/5)100%
(5/5)99%
(582/583)65%
(88/136)autotests.kcookiejar100%
(1/1)100%
(1/1)91%
(179/197)72%
(49/68)src100%
(1/1)100%
(1/1)86%
(6/7)67%
(4/6)src.core88%
(101/115)88%
(101/115)59%
(8492/14316)51%
(4463/8698)src.core.kssl100%
(1/1)100%
(1/1)40%
(35/88)50%
(3/6)src.filewidgets68%
(26/38)68%
(26/38)56%
(4694/8343)43%
(2079/4822)src.gui100%
(5/5)100%
(5/5)81%
(332/412)58%
(163/280)src.ioslaves.file100%
(7/7)100%
(7/7)55%
(714/1289)41%
(425/1040)src.ioslaves.file.kauth0%
(0/2)0%
(0/2)0%
(0/168)0%
(0/89)src.ioslaves.ftp100%
(2/2)100%
(2/2)47%
(646/1375)37%
(525/1420)src.ioslaves.help0%
(0/5)0%
(0/5)0%
(0/247)0%
(0/148)src.ioslaves.http88%
(7/8)88%
(7/8)42%
(1796/4287)36%
(1309/3628)src.ioslaves.http.kcookiejar40%
(2/5)40%
(2/5)48%
(634/1333)56%
(578/1029)src.ioslaves.remote100%
(2/2)100%
(2/2)27%
(74/270)8%
(14/184)src.ioslaves.remote.kdedmodule0%
(0/2)0%
(0/2)0%
 

KDE CI: Frameworks » kio » kf5-qt5 SUSEQt5.12 - Build # 567 - Fixed!

[CI System]

BUILD SUCCESS
 Build URL
https://build.kde.org/job/Frameworks/job/kio/job/kf5-qt5%20SUSEQt5.12/567/
 Project:
kf5-qt5 SUSEQt5.12
 Date of build:
Mon, 27 Apr 2020 19:45:51 +
 Build duration:
5 min 15 sec and counting
   BUILD ARTIFACTS
  acc/KF5KIO-5.70.0.xmllogs/KF5KIO/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: 0 test(s), Passed: 53 test(s), Skipped: 0 test(s), Total: 53 test(s)Name: projectroot.autotests Failed: 0 test(s), Passed: 6 test(s), Skipped: 0 test(s), Total: 6 test(s)Name: projectroot.src.ioslaves.trash Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)Name: projectroot.src.kpasswdserver Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)
   Cobertura Report
  
   Project Coverage Summary
  
   Name
  PackagesFilesClassesLinesConditionalsCobertura Coverage Report67%
(24/36)67%
(270/406)67%
(270/406)56%
(34932/62172)40%
(17738/43934)Coverage Breakdown by Package
Name
   FilesClassesLinesConditionalsautotests100%
(58/58)100%
(58/58)95%
(9812/10282)46%
(4582/9884)autotests.http100%
(5/5)100%
(5/5)99%
(582/583)65%
(88/136)autotests.kcookiejar100%
(1/1)100%
(1/1)91%
(179/197)72%
(49/68)src100%
(1/1)100%
(1/1)86%
(6/7)67%
(4/6)src.core88%
(101/115)88%
(101/115)59%
(8492/14316)51%
(4463/8698)src.core.kssl100%
(1/1)100%
(1/1)40%
(35/88)50%
(3/6)src.filewidgets68%
(26/38)68%
(26/38)56%
(4694/8341)43%
(2081/4826)src.gui100%
(5/5)100%
(5/5)81%
(332/412)58%
(163/280)src.ioslaves.file100%
(7/7)100%
(7/7)55%
(714/1289)41%
(425/1040)src.ioslaves.file.kauth0%
(0/2)0%
(0/2)0%
(0/168)0%
(0/89)src.ioslaves.ftp100%
(2/2)100%
(2/2)47%
(646/1375)37%
(525/1420)src.ioslaves.help0%
(0/5)0%
(0/5)0%
(0/247)0%
(0/148)src.ioslaves.http88%
(7/8)88%
(7/8)42%
(1791/4287)36%
(1311/3628)src.ioslaves.http.kcookiejar40%
(2/5)40%
(2/5)48%
(634/1333)56%
(578/1029)src.ioslaves.remote100%
(2/2)100%
(2/2)27%
(74/270)8%
(14/184)src.ioslaves.remote.kdedmodule0%
(0/2)0%
(0/2)0%

D29170: Detect executables without +x permission in $PATH to improve error message

[David Faure]

dfaure added a comment.


  In D29170#658605 , @ngraham wrote:
  
  > What does this mean for AppImages?
  
  
  They are not desktop files, they don't come into this code path (which takes 
a KService as input).
  
  Clicking on a +x AppImage asks for confirmation and runs it.

REPOSITORY
  R241 KIO

BRANCH
  2020_04_findExecutable

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

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

D29095: Change mouse icon to have better dark theme contrast

[Nathaniel Graham]

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


  Shipit!

REPOSITORY
  R266 Breeze Icons

BRANCH
  arcpatch-D29095

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

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

D29170: Detect executables without +x permission in $PATH to improve error message

[Nathaniel Graham]

ngraham added a comment.


  What does this mean for AppImages?

REPOSITORY
  R241 KIO

BRANCH
  2020_04_findExecutable

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

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

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

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks/job/kio/job/kf5-qt5%20SUSEQt5.14/67/
 Project:
kf5-qt5 SUSEQt5.14
 Date of build:
Mon, 27 Apr 2020 19:25:36 +
 Build duration:
12 min and counting
   BUILD ARTIFACTS
  acc/KF5KIO-5.70.0.xmllogs/KF5KIO/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: 52 test(s), Skipped: 0 test(s), Total: 53 test(s)Failed: projectroot.autotests.kiofilewidgets_knewfilemenutestName: projectroot.autotests Failed: 0 test(s), Passed: 6 test(s), Skipped: 0 test(s), Total: 6 test(s)Name: projectroot.src.ioslaves.trash Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)Name: projectroot.src.kpasswdserver Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)
   Cobertura Report
  
   Project Coverage Summary
  
   Name
  PackagesFilesClassesLinesConditionalsCobertura Coverage Report67%
(24/36)67%
(270/406)67%
(270/406)56%
(34940/62173)40%
(17738/43930)Coverage Breakdown by Package
Name
   FilesClassesLinesConditionalsautotests100%
(58/58)100%
(58/58)95%
(9812/10281)46%
(4582/9884)autotests.http100%
(5/5)100%
(5/5)99%
(582/583)65%
(88/136)autotests.kcookiejar100%
(1/1)100%
(1/1)91%
(179/197)72%
(49/68)src100%
(1/1)100%
(1/1)86%
(6/7)67%
(4/6)src.core88%
(101/115)88%
(101/115)59%
(8493/14316)51%
(4464/8698)src.core.kssl100%
(1/1)100%
(1/1)40%
(35/88)50%
(3/6)src.filewidgets68%
(26/38)68%
(26/38)56%
(4694/8343)43%
(2079/4822)src.gui100%
(5/5)100%
(5/5)81%
(332/412)58%
(163/280)src.ioslaves.file100%
(7/7)100%
(7/7)55%
(714/1289)41%
(425/1040)src.ioslaves.file.kauth0%
(0/2)0%
(0/2)0%
(0/168)0%
(0/89)src.ioslaves.ftp100%
(2/2)100%
(2/2)47%
(646/1375)37%
(525/1420)src.ioslaves.help0%
(0/5)0%
(0/5)0%
(0/247)0%
(0/148)src.ioslaves.http88%
(7/8)88%
(7/8)42%
(1796/4287)36%
(1309/3628)src.ioslaves.http.kcookiejar40%
(2/5)40%
(2/5)48%
(634/1333)56%
(578/1029)src.ioslaves.remote100%
(2/2)100%
(2/2)27%
(74/270)8%
(14/184)src.ioslaves.remote.kdedmodule0%
(0/2)0%
 

D29233: [Solid] Port foreach to range/index for

[David Faure]

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

REPOSITORY
  R245 Solid

BRANCH
  l-foreach-3 (branched from master)

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

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

D29229: [KPlotting] Port foreach (deprecated) to range for

[David Faure]

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

REPOSITORY
  R277 KPlotting

BRANCH
  l-foreach (branched from master)

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

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

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

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks/job/kio/job/kf5-qt5%20FreeBSDQt5.14/75/
 Project:
kf5-qt5 FreeBSDQt5.14
 Date of build:
Mon, 27 Apr 2020 19:25:36 +
 Build duration:
8 min 22 sec and counting
   JUnit Tests
  Name: projectroot Failed: 2 test(s), Passed: 50 test(s), Skipped: 0 test(s), Total: 52 test(s)Failed: projectroot.autotests.kiocore_jobtestFailed: projectroot.autotests.kiofilewidgets_knewfilemenutestName: projectroot.autotests Failed: 0 test(s), Passed: 6 test(s), Skipped: 0 test(s), Total: 6 test(s)Name: projectroot.src.ioslaves.trash Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)Name: projectroot.src.kpasswdserver Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)

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

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks/job/kio/job/kf5-qt5%20SUSEQt5.12/566/
 Project:
kf5-qt5 SUSEQt5.12
 Date of build:
Mon, 27 Apr 2020 19:25:36 +
 Build duration:
5 min 7 sec and counting
   BUILD ARTIFACTS
  acc/KF5KIO-5.70.0.xmllogs/KF5KIO/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: 52 test(s), Skipped: 0 test(s), Total: 53 test(s)Failed: projectroot.autotests.kiofilewidgets_knewfilemenutestName: projectroot.autotests Failed: 0 test(s), Passed: 6 test(s), Skipped: 0 test(s), Total: 6 test(s)Name: projectroot.src.ioslaves.trash Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)Name: projectroot.src.kpasswdserver Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)
   Cobertura Report
  
   Project Coverage Summary
  
   Name
  PackagesFilesClassesLinesConditionalsCobertura Coverage Report67%
(24/36)67%
(270/406)67%
(270/406)56%
(34944/62172)40%
(17742/43934)Coverage Breakdown by Package
Name
   FilesClassesLinesConditionalsautotests100%
(58/58)100%
(58/58)95%
(9812/10282)46%
(4586/9884)autotests.http100%
(5/5)100%
(5/5)99%
(582/583)65%
(88/136)autotests.kcookiejar100%
(1/1)100%
(1/1)91%
(179/197)72%
(49/68)src100%
(1/1)100%
(1/1)86%
(6/7)67%
(4/6)src.core88%
(101/115)88%
(101/115)59%
(8499/14316)51%
(4465/8698)src.core.kssl100%
(1/1)100%
(1/1)40%
(35/88)50%
(3/6)src.filewidgets68%
(26/38)68%
(26/38)56%
(4694/8341)43%
(2081/4826)src.gui100%
(5/5)100%
(5/5)81%
(332/412)58%
(163/280)src.ioslaves.file100%
(7/7)100%
(7/7)55%
(714/1289)41%
(425/1040)src.ioslaves.file.kauth0%
(0/2)0%
(0/2)0%
(0/168)0%
(0/89)src.ioslaves.ftp100%
(2/2)100%
(2/2)47%
(646/1375)37%
(525/1420)src.ioslaves.help0%
(0/5)0%
(0/5)0%
(0/247)0%
(0/148)src.ioslaves.http88%
(7/8)88%
(7/8)42%
(1796/4287)36%
(1309/3628)src.ioslaves.http.kcookiejar40%
(2/5)40%
(2/5)48%
(634/1333)56%
(578/1029)src.ioslaves.remote100%
(2/2)100%
(2/2)27%
(74/270)8%
(14/184)src.ioslaves.remote.kdedmodule0%
(0/2)0%
   

D29221: [FakeCdrom] Add a new UnknownMediumType enumerator to MediumType

[David Faure]

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

REPOSITORY
  R245 Solid

BRANCH
  l-mediumtypes (branched from master)

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

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

D29170: Detect executables without +x permission in $PATH to improve error message

[David Faure]

dfaure updated this revision to Diff 81377.
dfaure added a comment.


  Remove unused QFileInfo include

REPOSITORY
  R241 KIO

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29170?vs=81376=81377

BRANCH
  2020_04_findExecutable

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

AFFECTED FILES
  autotests/applicationlauncherjobtest.cpp
  src/core/desktopexecparser.cpp
  src/gui/kprocessrunner.cpp

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

D29216: Remove dead code since KF5.0: mount/umount devices in their contextmenu

[David Faure]

dfaure closed this revision.

REPOSITORY
  R241 KIO

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

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

D29170: Detect executables without +x permission in $PATH to improve error message

[David Faure]

dfaure updated this revision to Diff 81376.
dfaure added a comment.


  Remove QDir::current

REPOSITORY
  R241 KIO

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29170?vs=81275=81376

BRANCH
  2020_04_findExecutable

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

AFFECTED FILES
  autotests/applicationlauncherjobtest.cpp
  src/core/desktopexecparser.cpp
  src/gui/kprocessrunner.cpp

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

D29170: Detect executables without +x permission in $PATH to improve error message

[David Faure]

dfaure added inline comments.

INLINE COMMENTS

> ahmadsamir wrote in kprocessrunner.cpp:65
> I guess there is no need to use QDir::current() any more.

Good point, removing.

REPOSITORY
  R241 KIO

BRANCH
  2020_04_findExecutable

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

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

D29206: Move check for invalid service from KDesktopFileActions to ApplicationLauncherJob

[David Faure]

dfaure added inline comments.

INLINE COMMENTS

> ahmadsamir wrote in kprocessrunner.cpp:55
> IMHO, the word "entry" here is confusing, the first thing that comes to mind 
> is that an entry (i.e. a line) in the file is invalid.

I see what you're saying.

It's the name of the spec, though.
https://specifications.freedesktop.org/desktop-entry-spec/latest/

Each file is an "entry for the desktop", I guess.

REPOSITORY
  R241 KIO

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

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

Re: Information regarding upcoming Gitlab Migration

[Ben Cooksley]

On Tue, Apr 28, 2020 at 1:46 AM Nate Graham  wrote:
>
>
>
> On 4/27/20 4:38 AM, 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.
> >
> > e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is
> > krita graphics or its own thing?
>
> Trying to categorize everything into a single group cannot succeed
> because many projects could logically belong to multiple groups (e.g
> plasma-framework is a framework that's a part of Plasma; Discover is an
> app that's a part of Plasma; kdenetwork-filesharing and kio-extras are
> libraries that are distributed via the apps release service). I foresee
> endless pointless arguments about the best group for something to live in.

Sorry, but I don't think that will be a problem in reality.
Historically, back in the Subversion era, we had no choice but to
assign things to modules
(multimedia/graphics/office/network/games/etc) and we made that work
without much in the way of problems.

>
> Let's step back: do we have to put every repo inside a group in the
> first place? Is it solely so you can look at a nice list of all open
> merge requests for PIM/Frameworks/etc? If so, perhaps this workflow
> could be approximated with tags instead or group assignments instead

Given the complaints we have had around Phabricator, I can assure you
that tags/labels will not work.

People won't understand them, and we will have discoverability issues
with them especially for newcomers.

>
> We create many very granular groups for the purposes of organizing teams
> and and performing code review (e.g. Plasma, KWin, Frameworks, PIM,
> Krita, Dolphin, Okular, VDG, etc.) and then every new merge request
> could receive a tag or assignee corresponding to its relevant code
> review groups (e.g. merge requests for kio and kio-extras could get get
> tagged with both "Frameworks", and "Dolphin"; plasma-frameworks MRs
> could get tagged with both "Plasma" and "Frameworks", and so on).
>
> So +1 for a single top-level group I suppose.
>
> Nate

Regards,
Ben

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

[Carson Black]

cblack added inline comments.

INLINE COMMENTS

> ndavis wrote in kcolorscheme.h:133
> I think it would be good to explain the issue about enums being converted 
> into plain integers here so that people know why they shouldn't depend on it. 
> Also, is there a way to hide this from the api.kde.org page for kcolorscheme?

`#ifndef K_DOXYGEN`

REPOSITORY
  R265 KConfigWidgets

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

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

D29206: Move check for invalid service from KDesktopFileActions to ApplicationLauncherJob

[Ahmad Samir]

ahmadsamir added a comment.


  Otherwise makes sense.

INLINE COMMENTS

> kprocessrunner.cpp:55
> +if (!service->isValid()) {
> +emitDelayedError(i18n("The desktop entry file\n%1\nis not valid.", 
> service->entryPath()));
> +return;

IMHO, the word "entry" here is confusing, the first thing that comes to mind is 
that an entry (i.e. a line) in the file is invalid.

REPOSITORY
  R241 KIO

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

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

D29095: Change mouse icon to have better dark theme contrast

[Noah Davis]

ndavis edited the summary of this revision.

REPOSITORY
  R266 Breeze Icons

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

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

D29095: Change mouse icon to have better dark theme contrast

[Noah Davis]

ndavis updated this revision to Diff 81374.
ndavis added a comment.


  - Change kmousetool and preferences-desktop-mouse to symlinks

REPOSITORY
  R266 Breeze Icons

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29095?vs=81211=81374

BRANCH
  arcpatch-D29095

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

AFFECTED FILES
  icons-dark/apps/48/kmousetool.svg
  icons-dark/devices/64/input-mouse.svg
  icons-dark/preferences/32/preferences-desktop-mouse.svg
  icons/apps/48/kmousetool.svg
  icons/devices/64/input-mouse.svg
  icons/preferences/32/preferences-desktop-mouse.svg

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

D29095: Change mouse icon to have better dark theme contrast

[Noah Davis]

ndavis edited the summary of this revision.
ndavis edited the test plan for this revision.

REPOSITORY
  R266 Breeze Icons

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

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

D29231: [WIP] Add keyboard_shortcuts_inhibit protocol

[Roman Gilg]

romangg added inline comments.

INLINE COMMENTS

> zzag wrote in keyboard_shortcuts_inhibit_interface.cpp:129
> We probably need to ask folks in `#wayland` whether inhibitors outlive the 
> manager object.

In general objects created through some interface can outlive the interface 
bind if not otherwise specified in the protocol definition. I.e. the todo can 
be removed.

REPOSITORY
  R127 KWayland

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

To: bport, zzag, davidedmundson, apol
Cc: romangg, crossi, kde-frameworks-devel, LeGast00n, cblack, michaelh, 
ngraham, bruns

D28882: Create protocol to manage video feeds

[Vlad Zahorodnii]

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


  > In future, it might be faster to put up just the interface xml for review 
first.
  
  ++
  
  ---
  
  What about using existing `wl_output` objects? The `add_source` event can be 
simplified quite a lot (even maybe dropped). For windows, we could use string 
handles.
  

  
  
  



  
  
  

  
  Please notice that the manager object also needs to advertise supported 
cursor modes
  

  
  
  



  
  


INLINE COMMENTS

> screencast.xml:8
> +  ]]>
> +
> +

Interfaces usually come without `unstable` in the name.

s/zkde_screencast_unstable_v1/zkde_screencast_v1/

> screencast.xml:52-54
> +
> +
> +

zkde_screencast_stream_unstable_v1 must have a destructor request.

REPOSITORY
  R127 KWayland

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

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

D29101: KNewStuff: Fix file path and process call

[Nathaniel Graham]

ngraham added a reviewer: leinir.

REPOSITORY
  R304 KNewStuff

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

D29231: [WIP] Add keyboard_shortcuts_inhibit protocol

[Vlad Zahorodnii]

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


  I don't want to be selfish, but I'm not really used to the coding style in 
this patch. Could you please move method definitions outside class declarations?

INLINE COMMENTS

> keyboard_shortcuts_inhibit_interface.cpp:25
> +Private(wl_client *client, int id, SurfaceInterface *surface, 
> SeatInterface *seat, KeyboardShortcutsInhibitorInterface* q)
> +: zwp_keyboard_shortcuts_inhibitor_v1(client, id, s_version)
> +, q(q)

What if the client requested version < s_version? You need to create the 
resource manually.

> keyboard_shortcuts_inhibit_interface.cpp:129
> +Q_UNUSED(resource)
> +// TODO ensure we delete all inhibitors
> +delete q;

We probably need to ask folks in `#wayland` whether inhibitors outlive the 
manager object.

> keyboard_shortcuts_inhibit_interface.h:32
> +{
> +Q_OBJECT
> +public:

Indentation. Also, it's probably a minor thing, but it's really nice when 
Q_OBJECT is separated from code below by a single empty line (cosmetics).

> keyboard_shortcuts_inhibit_interface.h:60
> + */
> +KeyboardShortcutsInhibitorInterface 
> *getShortcutsInhibitor(SurfaceInterface *surface, SeatInterface *seat) const;
> +

We probably don't need it to be public. Only emit inhibitorCreated.

REPOSITORY
  R127 KWayland

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

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

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

[Marco Martin]

mart requested review of this revision.

REPOSITORY
  R265 KConfigWidgets

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

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

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

[Marco Martin]

mart retitled this revision from "[WIP][RFC]Introduce the Tools color set" to 
"[WIP][RFC]Introduce the Header color set".
mart edited the summary of this revision.
mart edited the test plan for this revision.

REPOSITORY
  R265 KConfigWidgets

BRANCH
  phab/toolsSet

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

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

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

[Noah Davis]

ndavis added inline comments.

INLINE COMMENTS

> kcolorscheme.h:133
>   * Number of color sets.
> + * Note: don't use this
>   * @since 5.65

I think it would be good to explain the issue about enums being converted into 
plain integers here so that people know why they shouldn't depend on it. Also, 
is there a way to hide this from the api.kde.org page for kcolorscheme?

REPOSITORY
  R265 KConfigWidgets

BRANCH
  phab/toolsSet

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

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

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

[Noah Davis]

ndavis added inline comments.

INLINE COMMENTS

> kcolorscheme.h:127
> +/**
> + * Colors for header areas that thould be used both by the top 
> toolbar and the titlebar titlebar.
> + * @since 5.69

- `thould`
- `titlebar titlebar`

REPOSITORY
  R265 KConfigWidgets

BRANCH
  phab/toolsSet

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

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

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

[Marco Martin]

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


  call it Header

REPOSITORY
  R265 KConfigWidgets

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29232?vs=81352=81363

BRANCH
  phab/toolsSet

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

AFFECTED FILES
  src/kcolorscheme.cpp
  src/kcolorscheme.h

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

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

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks/job/kio/job/kf5-qt5%20SUSEQt5.12/565/
 Project:
kf5-qt5 SUSEQt5.12
 Date of build:
Mon, 27 Apr 2020 16:04:46 +
 Build duration:
12 min and counting
   BUILD ARTIFACTS
  acc/KF5KIO-5.70.0.xmllogs/KF5KIO/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: 52 test(s), Skipped: 0 test(s), Total: 53 test(s)Failed: projectroot.autotests.kiofilewidgets_knewfilemenutestName: projectroot.autotests Failed: 0 test(s), Passed: 6 test(s), Skipped: 0 test(s), Total: 6 test(s)Name: projectroot.src.ioslaves.trash Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)Name: projectroot.src.kpasswdserver Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)
   Cobertura Report
  
   Project Coverage Summary
  
   Name
  PackagesFilesClassesLinesConditionalsCobertura Coverage Report67%
(24/36)67%
(270/406)67%
(270/406)56%
(34926/62172)40%
(17732/43942)Coverage Breakdown by Package
Name
   FilesClassesLinesConditionalsautotests100%
(58/58)100%
(58/58)95%
(9812/10282)46%
(4582/9884)autotests.http100%
(5/5)100%
(5/5)99%
(582/583)65%
(88/136)autotests.kcookiejar100%
(1/1)100%
(1/1)91%
(179/197)72%
(49/68)src100%
(1/1)100%
(1/1)86%
(6/7)67%
(4/6)src.core88%
(101/115)88%
(101/115)59%
(8481/14315)51%
(4459/8698)src.core.kssl100%
(1/1)100%
(1/1)40%
(35/88)50%
(3/6)src.filewidgets68%
(26/38)68%
(26/38)56%
(4694/8341)43%
(2081/4826)src.gui100%
(5/5)100%
(5/5)81%
(332/412)58%
(163/280)src.ioslaves.file100%
(7/7)100%
(7/7)55%
(714/1289)41%
(425/1040)src.ioslaves.file.kauth0%
(0/2)0%
(0/2)0%
(0/168)0%
(0/89)src.ioslaves.ftp100%
(2/2)100%
(2/2)47%
(646/1375)37%
(525/1420)src.ioslaves.help0%
(0/5)0%
(0/5)0%
(0/247)0%
(0/148)src.ioslaves.http88%
(7/8)88%
(7/8)42%
(1796/4287)36%
(1309/3628)src.ioslaves.http.kcookiejar40%
(2/5)40%
(2/5)48%
(634/1333)56%
(578/1029)src.ioslaves.remote100%
(2/2)100%
(2/2)27%
(74/270)8%
(14/184)src.ioslaves.remote.kdedmodule0%
(0/2)0%

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

[Noah Davis]

ndavis added a comment.


  I personally think it should be Header since Tools sound ambiguous and oddly 
limited to anyone unfamiliar with the context behind this patch

REPOSITORY
  R265 KConfigWidgets

BRANCH
  phab/toolsSet

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

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

Re: Information regarding upcoming Gitlab Migration

[Ilya Bizyaev]

Hello Bhushan!



Thank you for you work on the Gitlab migration!



The lists look good! Here are some ideas that I have, in case you think they 
can be considered before we transition:

• The "applications" category is somewhat misleading to me: it does not include 
all KDE applications, and not all repositories in that category are 
applications either. Looking through the list of projects in there, I think 
they can be safely distributed across other categories. Most complicated there 
are IMO kate, dolphin, klook, konqueror, konsole and yakuake. Somehow terminal 
emulators, file managers and text editors feel like they belong to the same 
category, but I don't know how to call it; maybe "files"?

• Tentative, but I think a category called "science" might make sense creating. 
Since KDE regularly attempts to promote usage of our software in scientific 
institutions, that wouldn't hurt either. E.g. Mark (an app for data science) 
doesn't really belong in "education", and I think is also true for labplot and 
rkward.

• I see a category named "others". Looking at its contents, maybe it can be 
renamed to "community"?



Looking forward to the move!



Cheers,

Ilya.





 Дата: Пн, 27 апр 2020 04:40:01 +0300 Bhushan Shah  
написал(а) 



[Please keep mailto:sysad...@kde.org list or mailto: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
 
 
-- 
Bhushan Shah 
http://blog.bshah.in 
IRC Nick : bshah on Freenode 
GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D

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

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks/job/kio/job/kf5-qt5%20FreeBSDQt5.14/74/
 Project:
kf5-qt5 FreeBSDQt5.14
 Date of build:
Mon, 27 Apr 2020 16:04:46 +
 Build duration:
8 min 11 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.kiofilewidgets_knewfilemenutestName: projectroot.autotests Failed: 0 test(s), Passed: 6 test(s), Skipped: 0 test(s), Total: 6 test(s)Name: projectroot.src.ioslaves.trash Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)Name: projectroot.src.kpasswdserver Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)

KDE CI: Frameworks » kio » kf5-qt5 SUSEQt5.14 - Build # 66 - Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks/job/kio/job/kf5-qt5%20SUSEQt5.14/66/
 Project:
kf5-qt5 SUSEQt5.14
 Date of build:
Mon, 27 Apr 2020 16:04:46 +
 Build duration:
5 min 19 sec and counting
   BUILD ARTIFACTS
  acc/KF5KIO-5.70.0.xmllogs/KF5KIO/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: 52 test(s), Skipped: 0 test(s), Total: 53 test(s)Failed: projectroot.autotests.kiofilewidgets_knewfilemenutestName: projectroot.autotests Failed: 0 test(s), Passed: 6 test(s), Skipped: 0 test(s), Total: 6 test(s)Name: projectroot.src.ioslaves.trash Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)Name: projectroot.src.kpasswdserver Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)
   Cobertura Report
  
   Project Coverage Summary
  
   Name
  PackagesFilesClassesLinesConditionalsCobertura Coverage Report67%
(24/36)67%
(270/406)67%
(270/406)56%
(34951/62175)40%
(17749/43938)Coverage Breakdown by Package
Name
   FilesClassesLinesConditionalsautotests100%
(58/58)100%
(58/58)95%
(9812/10281)46%
(4584/9884)autotests.http100%
(5/5)100%
(5/5)99%
(582/583)65%
(88/136)autotests.kcookiejar100%
(1/1)100%
(1/1)91%
(179/197)72%
(49/68)src100%
(1/1)100%
(1/1)86%
(6/7)67%
(4/6)src.core88%
(101/115)88%
(101/115)59%
(8499/14316)51%
(4468/8698)src.core.kssl100%
(1/1)100%
(1/1)40%
(35/88)50%
(3/6)src.filewidgets68%
(26/38)68%
(26/38)56%
(4694/8343)43%
(2079/4822)src.gui100%
(5/5)100%
(5/5)81%
(332/412)58%
(163/280)src.ioslaves.file100%
(7/7)100%
(7/7)55%
(714/1289)41%
(425/1040)src.ioslaves.file.kauth0%
(0/2)0%
(0/2)0%
(0/168)0%
(0/89)src.ioslaves.ftp100%
(2/2)100%
(2/2)47%
(646/1375)37%
(525/1420)src.ioslaves.help0%
(0/5)0%
(0/5)0%
(0/247)0%
(0/148)src.ioslaves.http88%
(7/8)88%
(7/8)42%
(1796/4287)36%
(1309/3628)src.ioslaves.http.kcookiejar40%
(2/5)40%
(2/5)48%
(634/1333)56%
(578/1029)src.ioslaves.remote100%
(2/2)100%
(2/2)27%
(74/270)8%
(14/184)src.ioslaves.remote.kdedmodule0%
(0/2)0%
   

D29231: [WIP] Add keyboard_shortcuts_inhibit protocol

[Benjamin Port]

bport updated this revision to Diff 81361.
bport added a comment.


  Use client not display for KeyboardShortcutsInhibitorInterface

REPOSITORY
  R127 KWayland

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29231?vs=81358=81361

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

AFFECTED FILES
  autotests/server/CMakeLists.txt
  autotests/server/test_keyboard_shortcuts_inhibitor_interface.cpp
  src/server/CMakeLists.txt
  src/server/display.cpp
  src/server/display.h
  src/server/keyboard_shortcuts_inhibit_interface.cpp
  src/server/keyboard_shortcuts_inhibit_interface.h

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

D29084: Make the HTML file template more useful

[Grzegorz Szymaszek]

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 R241:5adaa7cba102: Make the HTML file template more useful 
(authored by gszymaszek).

REPOSITORY
  R241 KIO

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29084?vs=80859=81360

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

AFFECTED FILES
  src/new_file_templates/HTMLFile.html

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

Re: Information regarding upcoming Gitlab Migration

[Nate Graham]

On 4/27/20 7:52 AM, Nate Graham wrote:

On 4/27/20 7:46 AM, Ingo Klöcker wrote:

On Montag, 27. April 2020 14:10:55 CEST Bhushan Shah wrote:

This is something which can be easily solved by Gitlab, Gitlab offers a
solution where project can be shared with another group.

So e.g. sharing kcontacts with kdepim should be possible, then all merge
requests/issues from kcontacts would show up under pim as well.


Great. So we could put all repos into an "all" group (e.g. rename kde 
to all)
and then have every subcommunity decide for themselves which repos 
they want

to see in their group.


If this is possible, it seems like the best solution to me.



I've just been informed that it's possible to have a project appear in 
multiple groups such that I could find plasma-frameworks in both the 
Frameworks and Plasma top-level groups.


Therefore I rescind my objection and endorse having many top-level 
groups instead of a single flat top-level namespace, provided that we do 
put projects that are related to multiple groups into those multiple groups.


Nate

Re: Information regarding upcoming Gitlab Migration

[Olivier Churlaud]

Hi,

Le lundi 27 avril 2020, 12:38:42 CEST Aleix Pol a écrit :
> On Mon, Apr 27, 2020 at 3:41 AM 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
> >

Thank you for having options and talking to us before implementing it.

> > 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
>
> 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.
>
> e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is
> krita graphics or its own thing?
>
> I really prefer when I don't have to guess this kind of things when
> fetching a repository.
>

I 100% agree with Aleix and I think it would also be detrimental for 
discoverability, exactly for the examples Aleix just gave.

We came back from this subgroups ideas some times ago : wiki pages were hard to 
find because hidden under layers of groups. The same was true for api 
documentations. Now everything is flat and I think it's easier to find.

Another bad message could also be sent by this: instead of exposing Konsole or 
Ark as two applications under the KDE umbrella, it would look like Utils for 
KDE, bringing back the KDE Desktop idea (where every application is already 
store in a submenu).

As someone wrote later, if I'm looking for a given application, there is always 
the search function...
  
Best regards,
Olivier
> Aleix

Re: Information regarding upcoming Gitlab Migration

[Ingo Klöcker]

On Montag, 27. April 2020 14:10:55 CEST Bhushan Shah wrote:
> [adding sysad...@kde.org in CC, please make sure you keep it in CC]
> 
> On Mon, Apr 27, 2020 at 02:03:48PM +0200, Ingo Klöcker wrote:
> > On Montag, 27. April 2020 13:19:07 CEST Ben Cooksley wrote:
> > > That requires that you know it exists. We have 1,043 mainline
> > > repositories at the moment, which translates to 53 pages of projects
> > > under a flat structure system.
> > > Reality is nobody is going to page through that looking for something.
> > 
> > I have to disagree. Whenever I'm looking for a project I browse
> > https://projects.kde.org/ (aka https://cgit.kde.org/).
> > Using a simple Ctrl+F in my browser allowed me to find what I was looking
> > for rather easily.
> > 
> > Having to look into *several* subgroups (because I guess we all know from
> > experience that any categorization into several groups never matches our
> > expectation) would have been a pain in the ass.
> > 
> > > Please also see my point regarding listing merge requests at the group
> > > level
> > 
> > This argument only holds if the subgroups match development teams. It does
> > already break down if e.g. a KDE PIM developer wants to see merge requests
> > for PIM related frameworks and for PIM applications.
> > 
> > I have experienced exactly this problem at work were we have put repos of
> > unrelated projects into different groups. It was extremely inconvenient
> > that, while working on more than one project at the same time, I couldn't
> > see all MRs I'm interested in on a single page.
> > 
> > IMNSHO the groups in GitLab are not the right solution for gathering all
> > repos some dev team, let alone individual devs, is/are interested in,
> > because the assumption that different dev teams are interested in
> > *disjoint* sets of repos is simply wrong. Moreover, the assumption that
> > all members of some dev team are interested in exactly the same repos is
> > equally wrong (even if most team members are probably interested in most
> > of the same repos).
> > 
> > And while the mapping group to dev team might make sense for something
> > like
> > plasma or frameworks or KDE PIM, I sure that it makes less or no sense for
> > groups like graphics were different teams are working on different
> > applications in the same group.
> > 
> > > - you can see an example of what a flat structure ends up
> > > looking like at https://gitlab.gnome.org/GNOME
> > > 
> > > For those projects that span multiple repositories, you have just
> > > denied them any chance or ability to see a listing of everything
> > > related to their wider project.
> > 
> > I'm sorry, but I don't think that this is solved by your proposal for the
> > KDE PIM projects because not everything related to KDE PIM (e.g. relevant
> > frameworks like kcontacts, kholidays, kpeople and soon kdav) will be in
> > the same group. The same is true for any project which uses some
> > frameworks, e.g. graphics and the imageformats framework or whatever
> > group kate and kwrite are going to end up in and the ktexteditor
> > framework.
> 
> This is something which can be easily solved by Gitlab, Gitlab offers a
> solution where project can be shared with another group.
> 
> So e.g. sharing kcontacts with kdepim should be possible, then all merge
> requests/issues from kcontacts would show up under pim as well.

Great. So we could put all repos into an "all" group (e.g. rename kde to all) 
and then have every subcommunity decide for themselves which repos they want 
to see in their group.

Regards,
Ingo


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

Re: Information regarding upcoming Gitlab Migration

[Olivier Churlaud]

Le lundi 27 avril 2020, 13:19:07 CEST Ben Cooksley a écrit :
> On Mon, Apr 27, 2020 at 11:12 PM Olivier Churlaud  
> wrote:
> >
> > Hi,
> >
> > Le lundi 27 avril 2020, 12:38:42 CEST Aleix Pol a écrit :
> > > On Mon, Apr 27, 2020 at 3:41 AM 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
> > > >
> >
> > Thank you for having options and talking to us before implementing it.
> >
> > > > 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
> > >
> > > 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.
> > >
> > > e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is
> > > krita graphics or its own thing?
> > >
> > > I really prefer when I don't have to guess this kind of things when
> > > fetching a repository.
> > >
> >
> > I 100% agree with Aleix and I think it would also be detrimental for 
> > discoverability, exactly for the examples Aleix just gave.
> >
> > We came back from this subgroups ideas some times ago : wiki pages were 
> > hard to find because hidden under layers of groups. The same was true for 
> > api documentations. Now everything is flat and I think it's easier to find.
> >
> > Another bad message could also be sent by this: instead of exposing Konsole 
> > or Ark as two applications under the KDE umbrella, it would look like Utils 
> > for KDE, bringing back the KDE Desktop idea (where every application is 
> > already store in a submenu).
> >
> > As someone wrote later, if I'm looking for a given application, there is 
> > always the search function...
> 
> That requires that you know it exists. We have 1,043 mainline
> repositories at the moment, which translates to 53 pages of projects
> under a flat structure system.
> Reality is nobody is going to page through that looking for something.
> 
> Please also see my point regarding listing merge requests at the group
> level - you can see an example of what a flat structure ends up
> looking like at https://gitlab.gnome.org/GNOME
> 
> For those projects that span multiple repositories, you have just
> denied them any chance or ability to see a listing of everything
> related to their wider project.

Maybe the middle ground would be to have applications and standalone libraries 
stored flat, and things that go together in a group, the same we tried to 
achieve on api.kde.org by defining products (either a repo or a group of 
repos). 

I guess that you would have
PIM/
Frameworks/

Re: Information regarding upcoming Gitlab Migration

[Nate Graham]

On 4/27/20 7:46 AM, Ingo Klöcker wrote:

On Montag, 27. April 2020 14:10:55 CEST Bhushan Shah wrote:

This is something which can be easily solved by Gitlab, Gitlab offers a
solution where project can be shared with another group.

So e.g. sharing kcontacts with kdepim should be possible, then all merge
requests/issues from kcontacts would show up under pim as well.


Great. So we could put all repos into an "all" group (e.g. rename kde to all)
and then have every subcommunity decide for themselves which repos they want
to see in their group.


If this is possible, it seems like the best solution to me.

Nate

Re: Information regarding upcoming Gitlab Migration

[Piyush Aggarwal]

On Mon, 27 Apr, 2020, 4:09 pm Aleix Pol,  wrote:

> On Mon, Apr 27, 2020 at 3:41 AM 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
>
> 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.
>
> e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is
> krita graphics or its own thing?
>
> I really prefer when I don't have to guess this kind of things when
> fetching a repository.
>
> Aleix
>

This is technical so I would love to hear Sysadmin team's thoughts on this:
Probably there can be a redirect system that lets us do git clone
kde:knotifications and manages to redirect it to
kde/frameworks/tier3/knotifications.git
So we can clone and tinker with stuff as we normally do while the sysadmin
team goes with the recommended system of setting up the repos.
I think this should be possible because Invent already redirects my URLs
which don't end with .git to .git ones. I might be wrong about my
assumption that both things can work similarly.

Best
Piyush Aggarwal

>

Re: Information regarding upcoming Gitlab Migration

[Nate Graham]

On 4/27/20 4:38 AM, 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.

e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is
krita graphics or its own thing?


Trying to categorize everything into a single group cannot succeed 
because many projects could logically belong to multiple groups (e.g 
plasma-framework is a framework that's a part of Plasma; Discover is an 
app that's a part of Plasma; kdenetwork-filesharing and kio-extras are 
libraries that are distributed via the apps release service). I foresee 
endless pointless arguments about the best group for something to live in.


Let's step back: do we have to put every repo inside a group in the 
first place? Is it solely so you can look at a nice list of all open 
merge requests for PIM/Frameworks/etc? If so, perhaps this workflow 
could be approximated with tags instead or group assignments instead


We create many very granular groups for the purposes of organizing teams 
and and performing code review (e.g. Plasma, KWin, Frameworks, PIM, 
Krita, Dolphin, Okular, VDG, etc.) and then every new merge request 
could receive a tag or assignee corresponding to its relevant code 
review groups (e.g. merge requests for kio and kio-extras could get get 
tagged with both "Frameworks", and "Dolphin"; plasma-frameworks MRs 
could get tagged with both "Plasma" and "Frameworks", and so on).


So +1 for a single top-level group I suppose.

Nate

D29233: [Solid] Port foreach to range/index for

[Ahmad Samir]

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

TEST PLAN
  make && ctest

REPOSITORY
  R245 Solid

BRANCH
  l-foreach-3 (branched from master)

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

AFFECTED FILES
  src/solid/devices/backends/upower/upowermanager.cpp
  src/solid/devices/backends/win/winblock.cpp
  src/solid/devices/backends/win/windevicemanager.cpp
  src/solid/devices/backends/win/winopticaldrive.cpp
  src/solid/devices/backends/win/winprocessor.cpp
  src/tools/solid-hardware/solid-hardware.cpp

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

D29231: [WIP] Add keyboard_shortcuts_inhibit protocol

[Aleix Pol Gonzalez]

apol added a comment.


  Code looks good overall, I'd say you'll get to polish the weird bits when 
developing the kwin side.
  
  In fact, this probably could be implemented within kwin considering what we 
discussed last week. We could remove the weirdness we have to keep its ABI.

INLINE COMMENTS

> keyboard_shortcuts_inhibit_interface.cpp:25
> +Private(Display *display, SurfaceInterface *surface, SeatInterface 
> *seat, KeyboardShortcutsInhibitorInterface* q)
> +: zwp_keyboard_shortcuts_inhibitor_v1(*display, s_version) // TODO 
> check we want to use display
> +, q(q)

You'll want to connect it to the respective client here, it's not a global 
anymore.

REPOSITORY
  R127 KWayland

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

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

D29231: [WIP] Add keyboard_shortcuts_inhibit protocol

[Benjamin Port]

bport updated this revision to Diff 81358.
bport marked an inline comment as done.
bport added a comment.


  added const to wrong line

REPOSITORY
  R127 KWayland

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29231?vs=81355=81358

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

AFFECTED FILES
  autotests/server/CMakeLists.txt
  autotests/server/test_keyboard_shortcuts_inhibitor_interface.cpp
  src/server/CMakeLists.txt
  src/server/display.cpp
  src/server/display.h
  src/server/keyboard_shortcuts_inhibit_interface.cpp
  src/server/keyboard_shortcuts_inhibit_interface.h

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

D29054: [Wayland] Add to PlasmaWindowManagement protocol windows stacking order

[Benjamin Port]

This revision was automatically updated to reflect the committed changes.
Closed by commit R127:185f40195dc0: [Wayland] Add to PlasmaWindowManagement 
protocol windows stacking order (authored by bport).

REPOSITORY
  R127 KWayland

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29054?vs=80901=81354

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

AFFECTED FILES
  src/client/plasmawindowmanagement.cpp
  src/client/plasmawindowmanagement.h
  src/client/protocols/plasma-window-management.xml
  src/client/registry.cpp
  src/server/plasmawindowmanagement_interface.cpp
  src/server/plasmawindowmanagement_interface.h

To: bport, zzag, davidedmundson
Cc: meven, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29231: [WIP] Add keyboard_shortcuts_inhibit protocol

[Benjamin Port]

bport updated this revision to Diff 81355.
bport added a comment.


  Cyril feedback

REPOSITORY
  R127 KWayland

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29231?vs=81351=81355

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

AFFECTED FILES
  autotests/server/CMakeLists.txt
  autotests/server/test_keyboard_shortcuts_inhibitor_interface.cpp
  src/server/CMakeLists.txt
  src/server/display.cpp
  src/server/display.h
  src/server/keyboard_shortcuts_inhibit_interface.cpp
  src/server/keyboard_shortcuts_inhibit_interface.h

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

D29231: [WIP] Add keyboard_shortcuts_inhibit protocol

[Benjamin Port]

bport edited the summary of this revision.

REPOSITORY
  R127 KWayland

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

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

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

[Nathaniel Graham]

ngraham added a task: T10201: Window titlebars.

REPOSITORY
  R265 KConfigWidgets

BRANCH
  phab/toolsSet

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

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

D29231: [WIP] Add keyboard_shortcuts_inhibit protocol

[Cyril Rossi]

crossi added inline comments.

INLINE COMMENTS

> keyboard_shortcuts_inhibit_interface.cpp:92
> +{
> +return d->m_surface;
> +}

indentation is missing

> keyboard_shortcuts_inhibit_interface.h:39
> +void setActive(bool active);
> +bool isActive();
> +private:

Should be const

REPOSITORY
  R127 KWayland

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

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

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

[Carson Black]

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


  +1 to the approach here. I assume this would probably replace the `WM` set in 
kdeglobals for all practical usage?

REPOSITORY
  R265 KConfigWidgets

BRANCH
  phab/toolsSet

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

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

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

[Marco Martin]

mart retitled this revision from "Introduce the Tools color set" to 
"[WIP][RFC]Introduce the Tools color set".

REPOSITORY
  R265 KConfigWidgets

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

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

D29232: Introduce the Tools color set

[Marco Martin]

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

REVISION SUMMARY
  This introduces two concepts: a new color set for Tools (or: titlebar?
  open question)
  and the possibility for a color set to have a different config group (a
  sub group) for different states (there, for inactive)
  
  the Tools area should probably also going to slowly relace the WM
  section of color themes
  
  This is needed for implement properly T10201 
, this graphical union
  between the titlebar and the toolbar.
  
  There is a problem of NColorSets that has been recently added,
  because it makes impossible to hard/impossible to
  properly add a set in a 100% abi compatible way, strictly speaking it
  should be compatible tough keeping NColorSets as the last value, is a
  kindof behavior change, though *should* be acceptable (old users would
  get the Tools value as NColorSets but everything working never the less)

TEST PLAN
  doing a color set with Tools group, the proper values get read

REPOSITORY
  R265 KConfigWidgets

BRANCH
  phab/toolsSet

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

AFFECTED FILES
  src/kcolorscheme.cpp
  src/kcolorscheme.h

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

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

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks/job/kwayland/job/kf5-qt5%20FreeBSDQt5.14/13/
 Project:
kf5-qt5 FreeBSDQt5.14
 Date of build:
Mon, 27 Apr 2020 15:22:51 +
 Build duration:
5 min 17 sec and counting
   JUnit Tests
  Name: projectroot.autotests Failed: 13 test(s), Passed: 30 test(s), Skipped: 0 test(s), Total: 43 test(s)Failed: projectroot.autotests.client.kwayland_testCompositorFailed: projectroot.autotests.client.kwayland_testDataDeviceFailed: projectroot.autotests.client.kwayland_testDataSourceFailed: projectroot.autotests.client.kwayland_testRegionFailed: projectroot.autotests.client.kwayland_testShmPoolFailed: projectroot.autotests.client.kwayland_testSubCompositorFailed: projectroot.autotests.client.kwayland_testSubSurfaceFailed: projectroot.autotests.client.kwayland_testWaylandConnectionThreadFailed: projectroot.autotests.client.kwayland_testWaylandRegistryFailed: projectroot.autotests.client.kwayland_testWaylandShellFailed: projectroot.autotests.client.kwayland_testWaylandSurfaceFailed: projectroot.autotests.client.kwayland_testXdgShellStableFailed: projectroot.autotests.server.kwayland_testWaylandServerDisplay

D29231: [WIP] Add keyboard_shortcuts_inhibit protocol

[Benjamin Port]

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

REVISION SUMMARY
  Depends on D29054 .

REPOSITORY
  R127 KWayland

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

AFFECTED FILES
  autotests/server/CMakeLists.txt
  autotests/server/test_keyboard_shortcuts_inhibitor_interface.cpp
  src/server/CMakeLists.txt
  src/server/display.cpp
  src/server/display.h
  src/server/keyboard_shortcuts_inhibit_interface.cpp
  src/server/keyboard_shortcuts_inhibit_interface.h

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

D29054: [Wayland] Add to PlasmaWindowManagement protocol windows stacking order

[Benjamin Port]

bport added a dependent revision: D29231: [WIP] Add keyboard_shortcuts_inhibit 
protocol.

REPOSITORY
  R127 KWayland

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

To: bport, zzag, davidedmundson
Cc: meven, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29222: Fix update auto selection

[Nathaniel Graham]

ngraham added a comment.


  Are you on a case-insensitive filesystem? :p
  
/home/nate/kde/src/knewstuff/src/core/engine.cpp: In member function ‘void 
KNSCore::Engine::downloadLinkLoaded(const KNSCore::EntryInternal&)’:
/home/nate/kde/src/knewstuff/src/core/engine.cpp:650:91: error: ‘filename’ 
was not declared in this scope; did you mean ‘fileName’?
  650 | qCDebug(KNEWSTUFFCORE) << "Found a suitable 
download link for" << filename << "which should match" << identifiedLink;
  | 
  ^~~~
  | 
  fileName

REPOSITORY
  R304 KNewStuff

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

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

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

[Nathaniel Graham]

ngraham added a comment.


  This version looks great to me!

REPOSITORY
  R242 Plasma Framework (Library)

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

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

D29188: [FileWatch] Remove redundant watchIndexedFolders() slot

[Stefan Brüns]

This revision was automatically updated to reflect the committed changes.
Closed by commit R293:1793785420b7: [FileWatch] Remove redundant 
watchIndexedFolders() slot (authored by bruns).

REPOSITORY
  R293 Baloo

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29188?vs=81201=81347

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

AFFECTED FILES
  autotests/unit/file/filewatchtest.cpp
  src/file/filewatch.cpp
  src/file/filewatch.h
  src/file/mainhub.cpp

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

D29188: [FileWatch] Remove redundant watchIndexedFolders() slot

[Nathaniel Graham]

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

REPOSITORY
  R293 Baloo

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

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

D29095: Change mouse icon to have better dark theme contrast

[Nathaniel Graham]

ngraham added a comment.


  +1, very nice.
  
  `icons/preferences/32/preferences-desktop-mouse.svg` still shows the old one 
from an earlier version of this patch.

REPOSITORY
  R266 Breeze Icons

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

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

D29200: test the extractNothing flag

[Nathaniel Graham]

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

REPOSITORY
  R286 KFileMetaData

BRANCH
  testNoExtraction

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

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

D29199: honor the extractMetaData flag

[Nathaniel Graham]

ngraham accepted this revision.

REPOSITORY
  R286 KFileMetaData

BRANCH
  honorFlag

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

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

D28882: Create protocol to manage video feeds

[Aleix Pol Gonzalez]

apol updated this revision to Diff 81341.
apol added a comment.


  Address review comments

REPOSITORY
  R127 KWayland

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D28882?vs=81113=81341

BRANCH
  master

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

AFFECTED FILES
  autotests/server/CMakeLists.txt
  autotests/server/test_screencasting.cpp
  src/client/CMakeLists.txt
  src/client/protocols/screencast.xml
  src/client/registry.cpp
  src/client/registry.h
  src/client/screencasting.cpp
  src/client/screencasting.h
  src/server/CMakeLists.txt
  src/server/display.cpp
  src/server/display.h
  src/server/screencasting_interface.cpp
  src/server/screencasting_interface.h

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

D28882: Create protocol to manage video feeds

[Aleix Pol Gonzalez]

apol marked 2 inline comments as done.

REPOSITORY
  R127 KWayland

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

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

D29223: Update Taiwanese holidays

[N. Higa]

nhiga added a comment.


  In D29223#658229 , @cgiboudeaux 
wrote:
  
  > I suppose you rename the file for a good reason. Are there different 
"official" languages for Taiwan?
  
  
  The new file name follows the same naming scheme used by the PRC (mainland 
China) holiday file, `holiday_cn_zh-cn` (holiday_region_Language-Region). It is 
also less ambiguous because `zh` alone does not indicate the character set 
being used (i.e. Simplified Chinese or Traditional Chinese).
  
  Actually the holiday file for Hong Kong, `holiday_hk_zh-cn`, should be 
renamed to `holiday_hk_zh-hk` because `zh-cn` means Simplified Chinese, but 
Hong Kong uses Traditional Chinese, but this will be another story.

REPOSITORY
  R175 KHolidays

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

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