Re: Broken Plasma 5.13 branch force-pushed.

[Bhushan Shah]

Hi James,

On Sat, Jun 02, 2018 at 10:46:10PM -0600, James Daniel Smith wrote:
> Hi;
> 
> These three commits are on the list of missed commits for 5.13 branch and 
> were 
> still un-restored for 5.13, so I cherry-picked them from master.
> 
> James



> Unfortunately as a result some commits were lost from 5.12, 5.13 and
> master branch, I've compiled list of the such commits for 5.12 and 5.13
> and master branch
> 
> - https://ptpb.pw/L799 master branch
> - https://ptpb.pw/O9RK Plasma/5.13 branch
> - for plasma 5.12 it's two commits of James
> 

Apologies for confusion, I think my original message was not clear, what
I meant to say was, commit those to specific branch only if they were
meant to be pushed to those branches, as the list was compiled by
comparing the wrong branch and correct branch, some commits included in
them were not meant to be there.

But I think, now everything is fixed. :-) and no commits needs to be
cherry-picked/merged.

Thanks!

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


signature.asc
Description: PGP signature

Broken Plasma 5.13 branch force-pushed.

[Bhushan Shah]

Hello Plasma team,

Appeareantly yesterday few commits slipped into Plasma/5.13 branch which
were meant to be just on master, branch. Morever this commits were
cherry-picked, so I am not sure if it was accident.

James, can you please clarify on this? Any reason you cherry-picked or
pushed those to Plasma/5.13 branch?

===
commit 2b5809b1d5ba35edeeb579274e03fc1058b936ff
Author: Furkan Tokac 
Date:   Sat May 19 14:36:58 2018 +0300

Workspace KCM Redesign Using Kirigami

commit c1f3b45cabe0cf89e13a5b1c9b7a673992320826
Author: Thomas Surrel 
Date:   Tue May 22 14:20:25 2018 -0600

Activity switcher auto-hide when using Meta-Tab

commit 14e5854152264647892545a02695fa659f0628bc
Author: Furkan Tokac 
Date:   Tue May 22 18:57:38 2018 +0300

Workspace KCM Code Improvement
===

We opted for force-pushing plasma 5.13 branch to avoid revert and then
merge into master and then reverting revert dance.

Thanks

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


signature.asc
Description: PGP signature

D13291: Use UDS_DISPLAY_NAME for file names.

[James Smith]

smithjd created this revision.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.
smithjd requested review of this revision.

REPOSITORY
  R126 KDE CLI Utilities

BRANCH
  master-lsfix

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

AFFECTED FILES
  kioclient/kioclient.cpp

To: smithjd
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D10297: Add new "Tools" button above System Monitor's process list

[Henrik Fehlauer]

rkflx added a comment.


  Awesome, I did not expect that the fix for the shortcuts would be so simple. 
Thanks for your patience, we are nearly there…

INLINE COMMENTS

> ksysguardprocesslist.cpp:421-427
> +//
> +// This is one way of how to find out the two required parameters for 
> the globalShortcut method
> +// (maybe there is a better one):
> +// auto list = 
> KGlobalAccel::getGlobalShortcutsByKey(QKeySequence(QStringLiteral("Alt+Space")));
> +// foreach (auto item, list) {
> +// qDebug() << item.componentUniqueName() << item.uniqueName();
> +// }

Left-over debug code?

> ksysguardprocesslist.cpp:429
> +auto runCommandShortcutList = 
> KGlobalAccel::self()->globalShortcut(QStringLiteral("krunner"), 
> QStringLiteral("run command"));
> +QString runCommandShortcut = i18nc("a keyboard shortcut", "not set");
> +if (runCommandShortcutList.size() > 0) {

Do you think it is really necessary to display `not set`? For me, an empty 
string would also work just fine, now that you are using `\t` instead of `(…)`.

Also I found a way to omit the string and `\t` entirely and let Qt do all the 
work:

  auto runCommandAction = new QAction(i18nc("@action:inmenu", "Run Command"), 
this);
  const auto runCommandShortcutList = 
KGlobalAccel::self()->globalShortcut(QStringLiteral("krunner"), 
QStringLiteral("run command"));
  if (runCommandShortcutList.size() > 0) {
  runCommandAction->setShortcut(runCommandShortcutList[0]);
  }

REPOSITORY
  R111 KSysguard Library

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

To: gregormi, #plasma, colomar, kossebau, broulik, mart, hein, rkflx
Cc: apol, anthonyfieroni, andreaska, rkflx, ngraham, plasma-devel, ragreen, 
Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, mart

D7087: Add "Copy Info" button to the About System KCM

[Henrik Fehlauer]

rkflx added a comment.


  Thanks for the update and sorry it took me a while to look at it.
  
  > If I remove that part, the button gets wider; I would prefer to keep it as 
small as possible.
  
  Ah, now I see where the problem is: You are inserting the button to a grid 
layout, which results in adding the button to the left of the logo (when 
looking at the left "columns" of the grid) instead of leaving the padding on 
the left alone and only adding it below the informational content and aligned 
to the left. This then causes the button to become wider.
  
  By fixing the overall layout and adding appropriate spacers, you should be 
able to go without setting a `Fixed` size policy for the button. Fixing the 
layout is required anyway, not sure why I didn't notice the huge gap on the 
left before. Try changing the window's width and compare to how it behaved 
before your patch to see what I mean.
  
  I'd arrange the UI like this:
  
  F5885212: about-distro-layout.png 
  
  (Simply draw a selection rectangle around the labels, click on "Grid", align 
button with new spacer in horizontal layout, remove 2 spacers, click on 
"Vertical Layout", adjust size.)

INLINE COMMENTS

> Module.cpp:260
> +if (!ui->nameVersionLabel->isHidden()) {
> +text += i18nc("one line in the information that goes to the 
> clipboard", "%1: %2", i18nc("label in the Copy to Clipboard button", 
> "Distro"), ui->nameVersionLabel->text()) + QStringLiteral("\n");
> +}

Maybe you could avoid this special case if you added a hidden label in 
`loadSoftware`?

Also, "label in … the button" sounds a bit odd. Perhaps "label" would be 
enough, or use `@title:row`? (See 
https://api.kde.org/frameworks/ki18n/html/prg_guide.html)

> Module.cpp:263
> +
> +foreach (auto p, labelsForClipboard) { // note that does not necessarily 
> represent the same order as in the GUI
> +auto descriptionLabelText = p.first->text();

I'd use the C++11 `for ( : )` here, and add `qAsConst` to the second argument 
since we can depend on Qt 5.7.

> Module.cpp:268
> +if (!valueLabel->isHidden()) {
> +if (descriptionLabelText.endsWith(":")) { // strip colon from 
> the end
> +descriptionLabelText = 
> descriptionLabelText.left(descriptionLabelText.length() - 1);

Is `endsWith` RTL aware? If not, it might be better to also check `startsWith`, 
however that assumes in most languages `:` is kept intact, which I'm not sure 
about.

Thinking about this again, why not

- keep the colon in the label
- don't add a colon in `%1 %2`
- change the context to `%1 is a label already including a colon, …`

> Module.cpp:271
> +}
> +text += i18nc("one line in the information that goes to the 
> clipboard", "%1: %2", descriptionLabelText, valueLabelText) + 
> QStringLiteral("\n");
> +}

> explain what the placeholders are meant to be. Leave it to the speakers of 
> the language the decision about the order.

I suspect @ltoscano meant something like this:

  %1 is a label, %2 is a corresponding value

"One line" is meaningless unless the translator also knows the other lines, and 
whether it is saved to the clipboard or a text file is probably also more 
confusing than helping.

> gregormi wrote in Module.ui:333-338
> If I remove that part, the button gets wider; I would prefer to keep it as 
> small as possible.

See reply in main comment.

> gregormi wrote in Module.ui:349-351
> The KStandardAction method seems only easily applicable with QToolButtons but 
> not with QPushButton. Furthermore, I got the "ambiguous key binding" when I 
> tried it. I now settled for QKeySequence::Copy which does not work for me but 
> at least results in no error message.

Works perfectly fine for me. I think there might be something off with your 
local shortcuts setup.

REPOSITORY
  R102 KInfoCenter

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

To: gregormi, ngraham, dhaumann, rkflx
Cc: rkflx, dhaumann, ltoscano, sebas, elvisangelaccio, cfeck, plasma-devel, 
ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, apol, 
mart

D13288: Fix the icons KCM

[Fabian Vogt]

fvogt added a comment.


  I didn't actually test this change as-is, I renamed the directory on-disk 
instead. Should have the same effect though.

REPOSITORY
  R119 Plasma Desktop

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

To: fvogt, #plasma
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D13288: Fix the icons KCM

[Fabian Vogt]

fvogt created this revision.
fvogt added a reviewer: Plasma.
Restricted Application added a project: Plasma.
fvogt requested review of this revision.

REVISION SUMMARY
  The aboutData's component name changed, but the kpackage did not get renamed.

TEST PLAN
  kcmshell5 icons works again.

REPOSITORY
  R119 Plasma Desktop

BRANCH
  Plasma/5.13

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

AFFECTED FILES
  kcms/icons/CMakeLists.txt

To: fvogt, #plasma
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D13274: Make drags from the Task Manager less prone to disaster

[David Edmundson]

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


  Title is a bit dramatic.
  
  I would suggest master only given we need to ensure we we've updated 
everything

REPOSITORY
  R119 Plasma Desktop

BRANCH
  master

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

To: hein, davidedmundson, Zren
Cc: ngraham, zzag, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

Re: Stepping down as maintainer

[David Edmundson]

Fair enough.

On the day to day side.

ZZag's and Anemeth have both been doing an amazing job lately on the
effects.
I'll continue on anything wrt rendering + wayland, hopefully Roman can
tackle anything on input and DRM.

Hopefully Thomas L will still be around as the relevant X wizz as that's a
domain I don't think anyone else wants to touch.

Collectively, we're all going to have to chip in on kwin bug triage, that's
an area where Martin has been doing an excellent job fo years.

I'm sure we'll be able to keep kwin awesome for the forseeable future.

David

Re: Stepping down as maintainer

[Eike Hein]

To establish the full extent of the range opinions here: Personally I think the 
VDG has been working very well lately, and I want to thank its members for 
being some of the most hard-working and motivated contributors to Plasma today. 
They've made my work better many times.

I also disagree that this has lead to sacrificing "product work at the altar of 
usability". Rather I believe the past 2-3 releases have finally brought us back 
to a strong focus precisely on product work, thanks in no small part to 
initiatives driven by the VDG communication hub. I think we've found a nice 
rhythm of the VDG generating actionable work items for code contributors to 
jump on and implement, and especially in the course of the System Settings 
work, the forth-and-back style of iterating together has lead to dramatically 
better results every time. The results are visible in our release announcements.

I believe the solution to any remaining woes lies in engagement, not in 
throwing hands up in the air and complaining. It's normal for coding and design 
teams to have some push-and-pull between them, that's how they complement and 
course-correct each other. It's also worth keeping in mind how frustrating it 
must be for design contributors if code contributors let them constantly feel 
that they are the final arbiters and gate-keepers, and resort to arguments from 
authority constantly. This is not what "common ownership" in the Manifesto is 
about. I urge code contributors to be aware of this harmful messaging, which 
sets us back on our quest to grow our talent mix, which has been paying 
dividends. This goes doubly so for maintainers, whose primary function is to 
enable the work of other - any - contributors. Let's keep in mind onboarding is 
one of our chosen community goals.

Finally, I want to say that I think it's not in good form to have started this 
discussion in this thread. Putting an entire set of contributors on trial under 
the mantle of someone's disgruntled exit announcement, biasing the burden of 
proof from the get-go? What are we doing here?


Cheers,
Eike
-- 
Plasma, apps developer
KDE e.V. vice president, treasurer
Seoul, South Korea

Re: Stepping down as maintainer

[Marco Martin]

Hi Martin,
Sorry to hear that, and thanks for your continued amazing work on kwin,
it's an amazing piece of software and I really think is one of the best
gems within KDE, something that no other project can rival in any way.
I'm with Roman asking you to reconsider, as we do still need guidance
before mastering enough, in the end of course it's your decision and yours
only.

Unfortunately I have to agree to many points of your analysis about the
VDG: it definitely has problems and a definite lack of direction and long
term vision.. it really needs leadership and some kind of reform.
You identified a problem that many of us are feeling as well, but It's
definitely our responsibility to make this work and some change there
happen.

--
Marco Martin

On Sat, Jun 2, 2018, 10:14 Martin Flöser  wrote:

> Hi all,
>
> After long consideration I decided that I am no longer in a position to
> be a maintainer. I currently do not follow up on reviews and hardly
> contribute any code. Given that I think it's time to pass on the torch.
> KWin is currently in a good position we have new developers working on
> various areas of KWin and my suggestion would be to split the task of
> maintainership on many shoulders, specialized for various areas.
>
> My lack of work lately was not just the lack of time, but to a larger
> degree a lack of motivation. I searched a lot for the reasons for the
> lack of motivation and I think I identified two core areas where KDE is
> currently heading to and where I just disagree with these directions.
> Please don't take my explanation personal, you are doing awesome work,
> it's just that I don't approve these directions. Lately I had a feeling
> of doing fundamental opposition to changes the community wants to do.
> Granted I think these changes are wrong, but I don't want to stand in
> the way, if that's what the people doing the work want.
>
> What I identified as the core issues is the way the VDG currently acts
> and the usability project.
>
> With the VDG I currently see the following problems:
>   * tendency to do changes and reverting them again
>   * taking easy solutions like flipping defaults without looking at the
> big picture
>   * tries to dictate much more than just visual or design
>   * does not consult domain experts
>   * presents final solution and disallows discussion as you were not part
> of the telegram discussion
>
> As examples I take the discussion around the change of lock screen
> wallpaper and the window decoration no border setting. In both cases the
> VDG identified a problem, which is great. But also presented the
> solution. In both cases the technical solution is bad and results in
> losing functionality. It takes a hard fight to convince the VDG that
> their solution is wrong and that something better is required. In the
> case of the lockscreen we succeeded. The new implementation is awesome,
> a clear improvement over the blue background and also over the one we
> had before. But if we would have taken the approach the VDG did without
> opposing and fighting we would have ended with a solution worse to the
> one we had before the blue background. To me this is a dangerous
> development. I don't want to have to fight for good solutions. That
> costs a lot of power and is not healthy for the community. My wish to
> the VDG would be to take a step back again and not trying to find the
> technical solution to the problems you identify. Please approach the
> developer community with "hey, we think this area is bad, we want to
> have these improvements, how can we achieve it?" What I also think is
> important is that you realize that changing a default is a technical
> solution. It's not just design. Ask the experts whether that is the
> right solution to your problem and don't dismiss their opinion based on
> "it's just design".
>
> Similar the no border discussion highlights some of these problems.
> While it sounds like a minor thing, it is not. We see the fundamental
> problems: domain experts are not consulted, if they chime in they are
> told that they have no saying in it as they were not part of the
> discussion. Changing the default has more consequences than just a
> visual one. I told that and nobody is listening. We are going the easy
> road of flipping defaults without thinking of the big picture or finding
> good solutions. This is not what we used to strive for in KDE. We used
> to operate on highest technical level trying to bring the best
> solutions. This is clearly not form follows function. We are removing
> function in the sake of form. A dangerous development. To get one thing
> clear: I don't care about whether no border or normal is the default,
> I'm not personal attached to this. What I care about is that we get the
> best solution for the users. And I am sure that changing this default
> will have negative impact. And that is sad.
>
> The second area where I really dislike the development KDE is taking is
> the usability project. I 

[Powerdevil] [Bug 350365] Battery monitor in tray randomly shows there is no battery

[Rolf Eike Beer]

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

--- Comment #21 from Rolf Eike Beer  ---
Still there in 5.12.5, and it seems to get worse as I see it more often.

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

[Powerdevil] [Bug 350365] Battery monitor in tray randomly shows there is no battery

[Rolf Eike Beer]

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

--- Comment #20 from Rolf Eike Beer  ---
*** Bug 394943 has been marked as a duplicate of this bug. ***

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

Re: Stepping down as maintainer

[Roman Gilg]

Hi Martin,

first of all thank you! KWin is an amazing piece of software and we
owe this to a huge part to you.

Regarding your decision to step down as maintainer I hope you
reconsider though. While it's true that you are currently not as
active as in the past, we still very much need your knowledge and
expertise on everything KWin/KWayland and X/Wayland related. This
holds definitely for bigger changes to KWin or KWayland like my
current output class restructuring in KWin or how there are at the
moment numerous new interfaces in the process of being added to
KWayland by different people.

When I saw there was a problem with stacking up reviews in the last
few weeks my secret plan was to still have you as maintainer of KWin
for the foreseeable future because of your immense knowledge about the
project, but at some point have David and/or me added as co-maintainer
to help with the legwork. Would this be an option for you?

Cheers,
Roman

Stepping down as maintainer

[Martin Flöser]

Hi all,

After long consideration I decided that I am no longer in a position to 
be a maintainer. I currently do not follow up on reviews and hardly 
contribute any code. Given that I think it's time to pass on the torch. 
KWin is currently in a good position we have new developers working on 
various areas of KWin and my suggestion would be to split the task of 
maintainership on many shoulders, specialized for various areas.


My lack of work lately was not just the lack of time, but to a larger 
degree a lack of motivation. I searched a lot for the reasons for the 
lack of motivation and I think I identified two core areas where KDE is 
currently heading to and where I just disagree with these directions. 
Please don't take my explanation personal, you are doing awesome work, 
it's just that I don't approve these directions. Lately I had a feeling 
of doing fundamental opposition to changes the community wants to do. 
Granted I think these changes are wrong, but I don't want to stand in 
the way, if that's what the people doing the work want.


What I identified as the core issues is the way the VDG currently acts 
and the usability project.


With the VDG I currently see the following problems:
 * tendency to do changes and reverting them again
 * taking easy solutions like flipping defaults without looking at the 
big picture

 * tries to dictate much more than just visual or design
 * does not consult domain experts
 * presents final solution and disallows discussion as you were not part 
of the telegram discussion


As examples I take the discussion around the change of lock screen 
wallpaper and the window decoration no border setting. In both cases the 
VDG identified a problem, which is great. But also presented the 
solution. In both cases the technical solution is bad and results in 
losing functionality. It takes a hard fight to convince the VDG that 
their solution is wrong and that something better is required. In the 
case of the lockscreen we succeeded. The new implementation is awesome, 
a clear improvement over the blue background and also over the one we 
had before. But if we would have taken the approach the VDG did without 
opposing and fighting we would have ended with a solution worse to the 
one we had before the blue background. To me this is a dangerous 
development. I don't want to have to fight for good solutions. That 
costs a lot of power and is not healthy for the community. My wish to 
the VDG would be to take a step back again and not trying to find the 
technical solution to the problems you identify. Please approach the 
developer community with "hey, we think this area is bad, we want to 
have these improvements, how can we achieve it?" What I also think is 
important is that you realize that changing a default is a technical 
solution. It's not just design. Ask the experts whether that is the 
right solution to your problem and don't dismiss their opinion based on 
"it's just design".


Similar the no border discussion highlights some of these problems. 
While it sounds like a minor thing, it is not. We see the fundamental 
problems: domain experts are not consulted, if they chime in they are 
told that they have no saying in it as they were not part of the 
discussion. Changing the default has more consequences than just a 
visual one. I told that and nobody is listening. We are going the easy 
road of flipping defaults without thinking of the big picture or finding 
good solutions. This is not what we used to strive for in KDE. We used 
to operate on highest technical level trying to bring the best 
solutions. This is clearly not form follows function. We are removing 
function in the sake of form. A dangerous development. To get one thing 
clear: I don't care about whether no border or normal is the default, 
I'm not personal attached to this. What I care about is that we get the 
best solution for the users. And I am sure that changing this default 
will have negative impact. And that is sad.


The second area where I really dislike the development KDE is taking is 
the usability project. I have a feeling currently everything is done in 
the sake of usability. We are losing the big picture, we are no longer 
doing product development. We don't try to improve the product and take 
it to the next level instead a thousand of minor things are added in the 
sake of usability. We ignore that every checkbox or option added 
decreases the usability for everybody else, we ignore the costs to 
maintain the code due to the changes. I remember that people like Björn, 
Kevin and Thomas told us that we should strive for satisfying 90 % of 
the userbase and not everyone. Currently we try to satisfy everyone. 
This is a road to failure in my opinion. We are on the road to KDE 3's 
configuration nightmare and creating an unmaintainable monster. We are 
working against plans we set for ourselves during the start of Plasma 5 
development such as focus on the core features and