D29354: Bash: fix comments after escapes

[Nibaldo González]

nibags edited the summary of this revision.

REPOSITORY
  R216 Syntax Highlighting

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

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

D29354: Bash: fix comments after escapes

[Nibaldo González]

nibags edited the summary of this revision.

REPOSITORY
  R216 Syntax Highlighting

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

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

D29354: Bash: fix comments after escapes

[Nibaldo González]

nibags created this revision.
nibags added reviewers: Framework: Syntax Highlighting, dhaumann, cullmann.
Herald added projects: Kate, Frameworks.
Herald added subscribers: kde-frameworks-devel, kwrite-devel.
nibags requested review of this revision.

REVISION SUMMARY
  BUG: 418876
  
  Comments were not highlighted after an escaped space, but this should only 
occur in commands.
  This is corrected: outside of a command, comments are highlighted after an 
escaped space.

REPOSITORY
  R216 Syntax Highlighting

BRANCH
  fix-comments-bash

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

AFFECTED FILES
  autotests/folding/highlight.sh.fold
  autotests/html/highlight.sh.html
  autotests/input/highlight.sh
  autotests/reference/highlight.sh.ref
  autotests/reference/test.bb.ref
  data/syntax/bash.xml

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

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

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks/job/kdelibs4support/job/kf5-qt5%20FreeBSDQt5.14/7/
 Project:
kf5-qt5 FreeBSDQt5.14
 Date of build:
Sat, 02 May 2020 03:59:00 +
 Build duration:
7 min 24 sec and counting
   JUnit Tests
  Name: projectroot Failed: 2 test(s), Passed: 37 test(s), Skipped: 0 test(s), Total: 39 test(s)Failed: projectroot.autotests.kmimetypetestFailed: projectroot.autotests.kstandarddirstest

Re: Information regarding upcoming Gitlab Migration

[Nate Graham]

On 5/1/20 2:09 PM, Ben Cooksley wrote:

Unfortunately sharing of projects/repositories across groups does not
impact on tasks and reviews.
This means that merge requests for Planet (which is currently shared
with "KDE") do not show up in the list of merge requests for "KDE".

Sharing repositories allows for a global listing only.
Are you saying that if we put plasma-framework in Plasma and share it 
with the Plasma group, then its MRs won't show up in the Plasma group's 
MR list? And that if we put it in the Plasma group and share it with the 
Frameworks group, then its MRs won't show up in the Frameworks group's 
MR list?


If so, that seems like it defeats one of the points of sharing a 
project/repo across groups. :(


Is this fixed in EE, or is it just a bug affecting all versions?

Nate

D29352: [Plasmoid Heading] Draw the heading only when there is an SVG in the theme

[Filip Fila]

filipf edited the test plan for this revision.
filipf added reviewers: VDG, Plasma.

REPOSITORY
  R242 Plasma Framework (Library)

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

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

D29352: [Plasmoid Heading] Draw the heading only when there is an SVG in the theme

[Filip Fila]

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

REVISION SUMMARY
  We're the only theme with the appropriate heading svgs that make the headers 
and footers look as they should.
  
  All the other themes fall back to Breeze, which is not a good look for some 
of them:
  
  - the heading is too jarring compared to applet background
  - the heading does not extend all the way vertically and horizontally
  
  To solve this, to avoid degrading unmaintained themes and to give themes a 
chance to adjust on their own terms, this patch makes the heading visible only 
when the needed SVG exists in the theme.

REPOSITORY
  R242 Plasma Framework (Library)

BRANCH
  heading-only-if-svg-exists (branched from master)

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

AFFECTED FILES
  src/declarativeimports/plasmaextracomponents/qml/PlasmoidHeading.qml

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

Re: Information regarding upcoming Gitlab Migration

[Ben Cooksley]

On Sat, May 2, 2020 at 9:04 AM Nate Graham  wrote:
>
> On 5/1/20 2:09 PM, Ben Cooksley wrote:
> > Unfortunately sharing of projects/repositories across groups does not
> > impact on tasks and reviews.
> > This means that merge requests for Planet (which is currently shared
> > with "KDE") do not show up in the list of merge requests for "KDE".
> >
> > Sharing repositories allows for a global listing only.
> Are you saying that if we put plasma-framework in Plasma and share it
> with the Plasma group, then its MRs won't show up in the Plasma group's
> MR list? And that if we put it in the Plasma group and share it with the
> Frameworks group, then its MRs won't show up in the Frameworks group's
> MR list?

That is correct.

>
> If so, that seems like it defeats one of the points of sharing a
> project/repo across groups. :(
>
> Is this fixed in EE, or is it just a bug affecting all versions?

It affects all versions.

>
> Nate

Regards,
Ben

Re: Information regarding upcoming Gitlab Migration

[Ben Cooksley]

On Sat, May 2, 2020 at 6:17 AM Alexander Potashev  wrote:
>
> On Tue, Apr 28, 2020 at 6:47 AM Bhushan Shah  wrote:
> > 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?
>
> Hi,

Hi Alexander,

>
> I have a similar use case. Sometimes I need to share a URL to a
> project. For this purpose I used to share e.g.
> https://cgit.kde.org/releaseme.git/about
>
> Does this migration make such permalinks impossible?
>
>
> From what I see, we lose permalinks because
>  1. cgit.kde.org will be discontinued

We provide the commits.kde.org redirector for permanent links.
Anywhere needing a long life link to a particular repository, commit,
etc (like documentation) should be using these links and not anything
else.

>  2. A once valid URL https://invent.kde.org/games/knetwalk may become
> unavailable if the project moves to another group, for example
> https://invent.kde.org/unmaintained/knetwalk
>

As mentioned by Nicolas, Gitlab maintains redirects so if such a move
were to take place, the above links would continue to work.
The only time this is not the case is when a new repository takes it's place.

> --
> Alexander Potashev

Cheers,
Ben

Re: Information regarding upcoming Gitlab Migration

[Ben Cooksley]

On Sat, May 2, 2020 at 2:33 AM Adriaan de Groot  wrote:
>
> On 2020 mayula d. 1id 07:08:41 CEST Ben Cooksley wrote:
> > On Fri, May 1, 2020 at 2:46 AM Nate Graham  wrote:
> > > If I'm understanding things, we have solutions to most or all of the
> > > objections raised so far:
> > >
> > > - Projects will be allowed to live in--or at least appear in--multiple
> > > top-level groups (e.g. plasma-framework could appear in both the
> > > Frameworks top-level group and also the Plasma top-level group)
> >
> > Projects will have the option to appear in multiple groups yes.
>
> Forgive me for coming full circle on this discussion, but
>
> - a group can have at most one workboard
> - a group offers some facilities for managing issues and reviews that cross
> over repositories within that group
> - a project (this is one-to-one with "repository", right?) can have as many
> workboards as it likes

Correct. Projects and repositories are the same thing, it is just a
matter of terminology.

>
> If a project can appear in more than one group, isn't the whole distinction
> between flat and namespaced a little ..

The ability for a project to appear in other groups is subject to some
limitations.
See https://invent.kde.org/groups/kde/-/shared for a list of
repositories currently shared with "KDE"

>
> well, how would this proposal fly?
>
> - Put everything in a single group called "kde" (this matches proposal 2 if I
> still remember the original numbering right -- flat, but not at top-level)

Proposal 2 had the groupings within a larger "KDE" group, rather than
at top level.

Proposal 1 was fully flat, just dump everything in one group.

> - Other groups hold things from "kde" (this matches proposal 3, giving more
> structure / hierarchy)
>
> People browsing *top* level would see group "kde" (for all I care, bookmark
> that one as "I want to browse the list of 1442 repositories") and a bunch of
> logical groups based on how the community organizes itself. People working
> inside a specific group can do their workboardy-things and focus on the
> repositories for that group, while people with an overall interest go to the
> KDE group.
>

Unfortunately sharing of projects/repositories across groups does not
impact on tasks and reviews.
This means that merge requests for Planet (which is currently shared
with "KDE") do not show up in the list of merge requests for "KDE".

Sharing repositories allows for a global listing only.

>
>
> Somehow I get the feeling that we started with some technical limitations
> which were driving particular choices, where those limitations aren't exactly
> what we assumed that they were, and now it looks to me like those limitations
> do not have to meaningfully impact *any* of the choices.
>
> (*if* my understanding is correct; I've been wrong enough times already today)
>
> [ade]

Cheers,
Ben

D29339: Implement updating of notifications on Android

[Nicolas Fella]

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

REPOSITORY
  R289 KNotifications

BRANCH
  master

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

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

D29342: Implement support for notification urgency on Android

[Nicolas Fella]

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

REPOSITORY
  R289 KNotifications

BRANCH
  master

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

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

D29335: Implement notification grouping on Android

[Nicolas Fella]

nicolasfella added inline comments.

INLINE COMMENTS

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

You have a point

REPOSITORY
  R289 KNotifications

BRANCH
  master

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

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

Re: Information regarding upcoming Gitlab Migration

[Nicolás Alvarez]

> On 1 May 2020, at 15:17, Alexander Potashev  wrote:
> 
> On Tue, Apr 28, 2020 at 6:47 AM Bhushan Shah  wrote:
>> 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?
> 
> Hi,
> 
> I have a similar use case. Sometimes I need to share a URL to a
> project. For this purpose I used to share e.g.
> https://cgit.kde.org/releaseme.git/about
> 
> Does this migration make such permalinks impossible?
> 
> 
> From what I see, we lose permalinks because
> 1. cgit.kde.org will be discontinued
> 2. A once valid URL https://invent.kde.org/games/knetwalk may become
> unavailable if the project moves to another group, for example
> https://invent.kde.org/unmaintained/knetwalk

As I understand it, games/knetwalk will become a redirect to 
unmaintained/knetwalk, so the old link will still work. This is handled by 
GitLab automatically. Even on gitlab.com, if you rename a repository on your 
personal account or transfer it to another group or user, the old name will 
forward to the new one.

-- 
Nicolás

D29347: KAuthorized: export method to reload restrictions

[David Faure]

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

REVISION SUMMARY
  This is useful for unittests. Example:
  
  KCONFIGCORE_EXPORT void reloadUrlActionRestrictions();
  
  void someTestMethod()
  {
  
KConfigGroup cg(KSharedConfig::openConfig(), "KDE URL Restrictions");
cg.writeEntry("rule_count", 1);
cg.writeEntry("rule_1", QStringList{"open", {}, {}, {}, "file", "", "", 
"false"});
cg.sync();
reloadUrlActionRestrictions();

// Some test for code that uses KUrlAuthorized

cg.deleteEntry("rule_1");
cg.deleteEntry("rule_count");
cg.sync();
reloadUrlActionRestrictions();
  
  }
  
  This is consistent with the fact that other functions used by
  KUrlAuthorized are defined here and exported internally.

TEST PLAN
  Used this in a KIO unittest I'm writing for the future OpenUrlJob

REPOSITORY
  R237 KConfig

BRANCH
  master

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

AFFECTED FILES
  src/core/kauthorized.cpp

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

Re: Information regarding upcoming Gitlab Migration

[Alexander Potashev]

On Tue, Apr 28, 2020 at 6:47 AM Bhushan Shah  wrote:
> 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?

Hi,

I have a similar use case. Sometimes I need to share a URL to a
project. For this purpose I used to share e.g.
https://cgit.kde.org/releaseme.git/about

Does this migration make such permalinks impossible?


>From what I see, we lose permalinks because
 1. cgit.kde.org will be discontinued
 2. A once valid URL https://invent.kde.org/games/knetwalk may become
unavailable if the project moves to another group, for example
https://invent.kde.org/unmaintained/knetwalk

--
Alexander Potashev

Re: Information regarding upcoming Gitlab Migration: clarifications

[Nate Graham]

On 5/1/20 9:02 AM, Johan Ouwerkerk wrote:

No, that is not the default.


Actually, it is: 
https://invent.kde.org/kde/kdesrc-build/-/blob/master/kdesrc-build-setup#L389




and download all
repos into ~/kde/src without any of the levels of hierarchy.



But it is sufficiently common that there is a dedicated setting for
it: `ignore-kde-structure`. Kinda does what it says on the tin ;)


Yes, and this setting is set by default. :)

Nate

Re: Information regarding upcoming Gitlab Migration: clarifications

[Luigi Toscano]

Ben Cooksley ha scritto:
> On Fri, May 1, 2020 at 4:38 PM Nate Graham  wrote:
>>
>>
>>
>> On 4/30/20 5:59 PM, Aleix Pol wrote:
>>> El jue., 30 de abr. de 2020 a la(s) 18:15, Albert Astals Cid
 Am I the only person that just has all the repos on the same folder? I 
 thought it was the common thing to do :?
>>>
>>> I do too
>>
>> Same here. kdesrc-build's default settings do this, and download all
>> repos into ~/kde/src without any of the levels of hierarchy. This would
>> seem to require unique repo names, no?
> 
> Not necessarily.
> 
> Git allows you to override the name that the local folder is called
> when cloning, so there is no reason why we can't specify something in
> the metadata to override the local name that the folder gets called in
> your local checkout folder.
> This would allow for example:
> 
> - frameworks/kcoreaddons on Gitlab continues to be called
> 'kcoreaddons' in your local checkout folder
> - maui/dialer on Gitlab gets called 'maui-dialer' in your local checkout 
> folder
> 
> This allows for the URLs on Gitlab to make sense, while simultaneously
> allowing your local source checkout folders to continue to work in the
> manner in which they do currently.
> Note that we do not expect people to hit this in many cases - this is
> about giving us the flexibility for the long term without imposing
> unnecessary bureaucracy and limits on projects within the KDE
> umbrella.
> 
> Automated tooling such as kdesrc-build and the proposed clone script
> (that searches in namespaces) should be able to handle this without
> much issue.
> In the case of manually done clones, it is reasonable to expect people
> to know what they're doing with their clones, and name them
> appropriately in the event they have a collision.
> 
> Does this sound acceptable?

I'd like to add that this would solve an issue we have on the translation side.

Right now, a few translation files use the repository names as the base part
of the template file name. For example, the translation files for the desktop
and json files, which are called ._desktop_.po(t) and
._json_.po(t) respectively.

In the case where the repository name is not unique we would need to record
the expected name for the template somewhere. If this  information is added to
the repository metadata, would have scripty rely on that and don't need to
write it down somewhere else.

So yes, if you can please add this optional override which sets a unique name
to the metadata, that would help, thanks!

-- 
Luigi

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

[Méven Car]

meven accepted this revision.

REPOSITORY
  R241 KIO

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

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

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

D29175: DBus Runner: Add service property to request actions once

[Méven Car]

meven added inline comments.

INLINE COMMENTS

> dbusrunnertest.cpp:204
> +// We haven't called the prepare slot, if the implementation works
> +// the actions should alredy be available
> +auto actions = m.actionsForMatch(fakeMatch);

typo: already

> dbusrunnertest.cpp:206
> +auto actions = m.actionsForMatch(fakeMatch);
> +QCOMPARE(actions.count(), 1);
> +

You should have added a QSignalSpy to check prepare was called, and another for 
requestAction to check it has been called only once.

REPOSITORY
  R308 KRunner

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

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

D29342: Implement support for notification urgency on Android

[Volker Krause]

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

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

REPOSITORY
  R289 KNotifications

BRANCH
  master

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

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

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

D28498: [xdgoutput] Explicitly set version of server interface

[David Edmundson]

davidedmundson abandoned this revision.
davidedmundson added a comment.


  All these problems go away with KWaylandServer \o/

REPOSITORY
  R127 KWayland

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

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

D29175: DBus Runner: Add service property to request actions once

[Alexander Lohnau]

This revision was automatically updated to reflect the committed changes.
Closed by commit R308:7b6222d8a10b: DBus Runner: Add service property to 
request actions once (authored by alex).

REPOSITORY
  R308 KRunner

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29175?vs=81623=81687

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

AFFECTED FILES
  autotests/dbusrunnertest.cpp
  autotests/dbusrunnertest.desktop
  src/data/servicetypes/plasma-runner.desktop
  src/dbusrunner.cpp

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

D29175: DBus Runner: Add service property to request actions once

[Nathaniel Graham]

ngraham accepted this revision.

REPOSITORY
  R308 KRunner

BRANCH
  request_actions_once (branched from master)

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

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

D29339: Implement updating of notifications on Android

[Volker Krause]

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

REPOSITORY
  R289 KNotifications

BRANCH
  master

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

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

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

Re: Information regarding upcoming Gitlab Migration: clarifications

[Johan Ouwerkerk]

On Fri, May 1, 2020 at 6:38 AM Nate Graham  wrote:
>
> On 4/30/20 5:59 PM, Aleix Pol wrote:
> > El jue., 30 de abr. de 2020 a la(s) 18:15, Albert Astals Cid
> >> Am I the only person that just has all the repos on the same folder? I 
> >> thought it was the common thing to do :?
> >
> > I do too
>
> Same here. kdesrc-build's default settings do this,
>

No, that is not the default. By default the hierarchy is mirrored.

> and download all
> repos into ~/kde/src without any of the levels of hierarchy.
>

But it is sufficiently common that there is a dedicated setting for
it: `ignore-kde-structure`. Kinda does what it says on the tin ;)

> This would
> seem to require unique repo names, no?
>

Yes, it does.

Also whether the hierarchy is preserved locally or not, kdesrc-build
currently requires that the leaf names ($repo.git) be unique. It
cannot fully and consistently distinguish between a maui/dialer and a
plasma-mobile/dialer because at certain points in Perl we map to/from
module names which are mapped onto those leaf names (i.e. both would
be considered "dialer" and it would be anybody's guess at this point
what you'd get if you did a `kdesrc-build dialer`).

Might be fixable, but is definitely not trivial and would require
people to help review and test. Also would require some "cleverness"
to preserve the ability to refer to modules by their leaf names when
possible (i.e. continuing to be able to do `kdesrc-build kate`),
otherwise kdesrc-build becomes a *lot* less user friendly all of a
sudden.

Regards,

- Johan

D29335: Implement notification grouping on Android

[Volker Krause]

vkrause added inline comments.

INLINE COMMENTS

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

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

REPOSITORY
  R289 KNotifications

BRANCH
  master

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

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

Re: Information regarding upcoming Gitlab Migration: clarifications

[Aleix Pol]

On Fri, May 1, 2020 at 7:18 AM Ben Cooksley  wrote:
>
> On Fri, May 1, 2020 at 4:38 PM Nate Graham  wrote:
> >
> >
> >
> > On 4/30/20 5:59 PM, Aleix Pol wrote:
> > > El jue., 30 de abr. de 2020 a la(s) 18:15, Albert Astals Cid
> > >> Am I the only person that just has all the repos on the same folder? I 
> > >> thought it was the common thing to do :?
> > >
> > > I do too
> >
> > Same here. kdesrc-build's default settings do this, and download all
> > repos into ~/kde/src without any of the levels of hierarchy. This would
> > seem to require unique repo names, no?
>
> Not necessarily.
>
> Git allows you to override the name that the local folder is called
> when cloning, so there is no reason why we can't specify something in
> the metadata to override the local name that the folder gets called in
> your local checkout folder.
> This would allow for example:
>
> - frameworks/kcoreaddons on Gitlab continues to be called
> 'kcoreaddons' in your local checkout folder
> - maui/dialer on Gitlab gets called 'maui-dialer' in your local checkout 
> folder
>
> This allows for the URLs on Gitlab to make sense, while simultaneously
> allowing your local source checkout folders to continue to work in the
> manner in which they do currently.
> Note that we do not expect people to hit this in many cases - this is
> about giving us the flexibility for the long term without imposing
> unnecessary bureaucracy and limits on projects within the KDE
> umbrella.
>
> Automated tooling such as kdesrc-build and the proposed clone script
> (that searches in namespaces) should be able to handle this without
> much issue.
> In the case of manually done clones, it is reasonable to expect people
> to know what they're doing with their clones, and name them
> appropriately in the event they have a collision.
>
> Does this sound acceptable?

Okay, if that's necessary, we'll have to do it.

We'll appreciate simpler bureaucracy.

Aleix

Re: Information regarding upcoming Gitlab Migration

[Adriaan de Groot]

On 2020 mayula d. 1id 07:08:41 CEST Ben Cooksley wrote:
> On Fri, May 1, 2020 at 2:46 AM Nate Graham  wrote:
> > If I'm understanding things, we have solutions to most or all of the
> > objections raised so far:
> > 
> > - Projects will be allowed to live in--or at least appear in--multiple
> > top-level groups (e.g. plasma-framework could appear in both the
> > Frameworks top-level group and also the Plasma top-level group)
> 
> Projects will have the option to appear in multiple groups yes.

Forgive me for coming full circle on this discussion, but

- a group can have at most one workboard
- a group offers some facilities for managing issues and reviews that cross 
over repositories within that group
- a project (this is one-to-one with "repository", right?) can have as many 
workboards as it likes

If a project can appear in more than one group, isn't the whole distinction 
between flat and namespaced a little .. 

well, how would this proposal fly?

- Put everything in a single group called "kde" (this matches proposal 2 if I 
still remember the original numbering right -- flat, but not at top-level)
- Other groups hold things from "kde" (this matches proposal 3, giving more 
structure / hierarchy)

People browsing *top* level would see group "kde" (for all I care, bookmark 
that one as "I want to browse the list of 1442 repositories") and a bunch of 
logical groups based on how the community organizes itself. People working 
inside a specific group can do their workboardy-things and focus on the 
repositories for that group, while people with an overall interest go to the 
KDE group.



Somehow I get the feeling that we started with some technical limitations 
which were driving particular choices, where those limitations aren't exactly 
what we assumed that they were, and now it looks to me like those limitations 
do not have to meaningfully impact *any* of the choices.

(*if* my understanding is correct; I've been wrong enough times already today)

[ade]

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

D29335: Implement notification grouping on Android

[Nicolas Fella]

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


  Haven't tested it, but the code looks sensible

INLINE COMMENTS

> NotifyByAndroid.java:171
> +Notification.Builder builder;
> +if (Build.VERSION.SDK_INT >= 26) {
> +builder = new Notification.Builder(m_ctx, 
> notification.channelId);

Please use 
https://developer.android.com/reference/android/os/Build.VERSION_CODES instead 
of hardcoding numbers

REPOSITORY
  R289 KNotifications

BRANCH
  master

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

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

D29021: Remove checks for notification service and fallback to KPassivePopup

[Nicolas Fella]

nicolasfella added a dependent revision: D29336: Remove galago from 
method/variable naming.

REPOSITORY
  R289 KNotifications

BRANCH
  nofallback2

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

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

D29336: Remove galago from method/variable naming

[Nicolas Fella]

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

REVISION SUMMARY
  With D29021  the fallback notification 
system is gone and with it the need for differentating naming. Remove galago 
from the naming since it's outdated and might confuse readers unfamiliar with 
the code and its history. Also inline a now not needed function.

TEST PLAN
  Still get notifications, action invoked signal is correctly sent
  
  Depends on D29021 

REPOSITORY
  R289 KNotifications

BRANCH
  nogalago

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

AFFECTED FILES
  src/imageconverter.h
  src/notifybypopup.cpp
  src/notifybypopup.h
  src/notifybyportal.cpp

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

D29335: Implement notification grouping on Android

[Volker Krause]

vkrause added a comment.


  Collapsed: F8276057: Screenshot_20200501_161952.PNG 

  Expanded: F8276059: Screenshot_20200501_162043.PNG 


REPOSITORY
  R289 KNotifications

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

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

D29335: Implement notification grouping on Android

[Volker Krause]

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

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

REPOSITORY
  R289 KNotifications

BRANCH
  master

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

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

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

Re: Information regarding upcoming Gitlab Migration: clarifications

[Allen Winter]

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

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

Re: Information regarding upcoming Gitlab Migration

[Nate Graham]

Thanks for the clarifications, Ben. Then I think the original proposal 
is perfectly reasonable and I fully support it.


Nate

Re: Information regarding upcoming Gitlab Migration: clarifications

[Nate Graham]

On 4/30/20 11:17 PM, Ben Cooksley wrote:

Not necessarily.

Git allows you to override the name that the local folder is called
when cloning, so there is no reason why we can't specify something in
the metadata to override the local name that the folder gets called in
your local checkout folder.
This would allow for example:

- frameworks/kcoreaddons on Gitlab continues to be called
'kcoreaddons' in your local checkout folder
- maui/dialer on Gitlab gets called 'maui-dialer' in your local checkout folder

This allows for the URLs on Gitlab to make sense, while simultaneously
allowing your local source checkout folders to continue to work in the
manner in which they do currently.
Note that we do not expect people to hit this in many cases - this is
about giving us the flexibility for the long term without imposing
unnecessary bureaucracy and limits on projects within the KDE
umbrella.

Automated tooling such as kdesrc-build and the proposed clone script
(that searches in namespaces) should be able to handle this without
much issue.
In the case of manually done clones, it is reasonable to expect people
to know what they're doing with their clones, and name them
appropriately in the event they have a collision.

Does this sound acceptable?


A little weird, but probably acceptable. I suppose it's no worse than 
having discover build an executable called "plasma-discover", which 
trips me up like five times a day :)


Nate

D29198: filenamesearch:/ define a title for the query

[Ismael Asensio]

iasensio accepted this revision.
iasensio added a comment.


  Sorry I missed the ping.
  Along with D29197 , it looks nice to me.

INLINE COMMENTS

> dolphinsearchbox.cpp:479
> +return i18nc("@title UDS_DISPLAY_NAME for a KIO directory listing. %1 is 
> the query the user entered.",
> + "Query Results from '%1'", text);
> +}

Please, align the two strings

> elvisangelaccio wrote in dolphinsearchbox.h:164
> Please drop the `get` prefix.

I'd move this line up to separate private methods from private member variables

REPOSITORY
  R318 Dolphin

BRANCH
  arcpatch-D29198_1

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

To: meven, ngraham, elvisangelaccio, #dolphin, #frameworks, iasensio
Cc: iasensio, kfm-devel, azyx, nikolaik, pberestov, aprcela, fprice, 
fbampaloukas, alexde, Codezela, feverfew, meven, spoorun, navarromorales, 
firef, ngraham, andrebarros, emmanuelp, rdieter, mikesomov

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

[Nicolas Fella]

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

REPOSITORY
  R289 KNotifications

BRANCH
  master

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

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

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

[Volker Krause]

vkrause added a comment.


  F8275264: Screenshot_20200501_124105.PNG 


REPOSITORY
  R289 KNotifications

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

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

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

[Volker Krause]

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

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

REPOSITORY
  R289 KNotifications

BRANCH
  master

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

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

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

D29136: Use non-deprecated KDEInstallDir

[Heiko Becker]

heikobecker reclaimed this revision.

REPOSITORY
  R249 KI18n

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

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

Re: Information regarding upcoming Gitlab Migration: clarifications

[Nate Graham]

On 4/30/20 5:59 PM, Aleix Pol wrote:

El jue., 30 de abr. de 2020 a la(s) 18:15, Albert Astals Cid

Am I the only person that just has all the repos on the same folder? I thought 
it was the common thing to do :?


I do too


Same here. kdesrc-build's default settings do this, and download all 
repos into ~/kde/src without any of the levels of hierarchy. This would 
seem to require unique repo names, no?


The group categorization we've been discussing may be useful on the web 
UI for newcomers, but it has no value for your source checkout folder 
IMO, where it just makes it slightly more annoying to navigate from one 
repo to another.


Nate

D29175: DBus Runner: Add service property to request actions once

[Alexander Lohnau]

alex added a dependent revision: D29320: Baloo Runner: Use 
X-Plasma-Request-Actions-Once property in service.

REPOSITORY
  R308 KRunner

BRANCH
  request_actions_once (branched from master)

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

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

D29198: filenamesearch:/ define a title for the query

[Méven Car]

meven added a comment.


  @iasensio Does this look good to you.
  
  Btw @elvisangelaccio I am editing the filenamesearch:/ ioslave in D29197 
 so I know this can't create an issue.
  The title in the baloo case also ends up in the ioslave query url's argument 
title.

REPOSITORY
  R318 Dolphin

BRANCH
  arcpatch-D29198_1

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

To: meven, ngraham, elvisangelaccio, #dolphin, #frameworks
Cc: iasensio, kfm-devel, azyx, nikolaik, pberestov, aprcela, fprice, 
fbampaloukas, alexde, Codezela, feverfew, meven, spoorun, navarromorales, 
firef, ngraham, andrebarros, emmanuelp, rdieter, mikesomov