[Breeze] [Bug 395010] If scroll up/down buttons are visible, always show them in the scrollbar gutter

[Hugo Pereira Da Costa]

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

Hugo Pereira Da Costa  changed:

   What|Removed |Added

 CC||hugo.pereira.da.costa@gmail
   ||.com
   Assignee|hugo.pereira.da.costa@gmail |plasma-devel@kde.org
   |.com|

--- Comment #2 from Hugo Pereira Da Costa  ---
Hint. 
The action is not in ./kstyle/animations/breezescrollbardata.cpp

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

Stepping down as maintainer for breeze/oxygen kstyle and deco

[Hugo Pereira Da Costa]

Title says it all.

No need for long explanations, I am just not enjoying it any more.
Time to move on, sorry.

Best of luck,

Hugo

D11175: [kstyle] Refine shadows

[Vlad Zagorodniy]

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


  Rebase.

REPOSITORY
  R31 Breeze

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D11175?vs=34595=35491

BRANCH
  refine-shadows

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

AFFECTED FILES
  kstyle/CMakeLists.txt
  kstyle/breeze.kcfg
  kstyle/breezemdiwindowshadow.cpp
  kstyle/breezeshadowhelper.cpp
  kstyle/breezeshadowhelper.h

To: zzag, #breeze, #vdg, hpereiradacosta
Cc: abetts, ngraham, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, sebas, apol, mart

D11069: [kdecoration] Refine shadows

[Vlad Zagorodniy]

zzag updated this revision to Diff 35489.
zzag added a comment.
This revision is now accepted and ready to land.


  Drop HiDPI support.

REPOSITORY
  R31 Breeze

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D11069?vs=35488=35489

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

AFFECTED FILES
  kdecoration/CMakeLists.txt
  kdecoration/breezedecoration.cpp
  kdecoration/breezesettingsdata.kcfg

To: zzag, #breeze, #vdg, hpereiradacosta
Cc: abetts, fabianr, hpereiradacosta, ngraham, plasma-devel, ragreen, Pitel, 
ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol, mart

D11069: [kdecoration] Refine shadows

[Vlad Zagorodniy]

zzag planned changes to this revision.
zzag added a comment.


  OK, the issue above is still present. Need to fix this somehow.

REPOSITORY
  R31 Breeze

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

To: zzag, #breeze, #vdg, hpereiradacosta
Cc: abetts, fabianr, hpereiradacosta, ngraham, plasma-devel, ragreen, Pitel, 
ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol, mart

D11069: [kdecoration] Refine shadows

[Vlad Zagorodniy]

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


  Wrong comparison

REPOSITORY
  R31 Breeze

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D11069?vs=35487=35488

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

AFFECTED FILES
  kdecoration/CMakeLists.txt
  kdecoration/breezedecoration.cpp
  kdecoration/breezesettingsdata.kcfg

To: zzag, #breeze, #vdg, hpereiradacosta
Cc: abetts, fabianr, hpereiradacosta, ngraham, plasma-devel, ragreen, Pitel, 
ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol, mart

D11069: [kdecoration] Refine shadows

[Vlad Zagorodniy]

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


  Do not allow dpr < 1.

REPOSITORY
  R31 Breeze

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D11069?vs=34594=35487

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

AFFECTED FILES
  kdecoration/CMakeLists.txt
  kdecoration/breezedecoration.cpp
  kdecoration/breezesettingsdata.kcfg

To: zzag, #breeze, #vdg, hpereiradacosta
Cc: abetts, fabianr, hpereiradacosta, ngraham, plasma-devel, ragreen, Pitel, 
ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol, mart

D13292: Centre align SystemLoadViewer headers

[David Edmundson]

This revision was automatically updated to reflect the committed changes.
Closed by commit R114:11e9f3d16c06: Centre align SystemLoadViewer headers 
(authored by davidedmundson).

REPOSITORY
  R114 Plasma Addons

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13292?vs=35440=35484

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

AFFECTED FILES
  applets/systemloadviewer/package/contents/ui/SystemLoadViewer.qml

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

D13292: Centre align SystemLoadViewer headers

[Nathaniel Graham]

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


  +1. And this will be a good test of {T8931}. :)

REPOSITORY
  R114 Plasma Addons

BRANCH
  master

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

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

Re: Stepping down as maintainer

[Eike Hein]

On 06/03/2018 07:05 PM, Martin Flöser wrote:
> Am 2018-06-02 13:43, schrieb 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".
>
> our experiences seem to differ here.

I think this is true, and I think it's helpful to talk about my
experiences a bit more to understand where it's coming from. What
follows is a lot of talk about KCM rewrites, which I know you haven't
been closely involved in, but I think it's worth a read for some of the
higher-level points.

Most of my recent experience working with the VDG has been in context of
the System Settings rewrite project. I've rewritten a bunch of KCMs now,
and for me the process has been like so:

1. The VDG did a large set of first wave mockups, one for each mockup.
Find the mockup.

2. Look at it, find the immediate "this is not going to work" gotchas
and have a brief chat about it with the VDG.

3. Implement a first rough version based on the mockup and the conversation.

4. Put up the rough first version on Phabricator for review. Invite the
VDG to comment. Iterate together both with the VDG, as well as with KF5
upstream on the technical side to get lib ducks in a row to support the
new UI.

So it's been an iterative ping-pong thing. Some notes on this:

* I find that having an initial mockup to implement improves my
productivity as a developer. Having a known target to implement is a
much more brisk process vs. inventing an UI from scratch myself during
coding.

* As we do more and more KCMs, it's increasingly become a bit
problematic that the first-wave KCM mockups are a bit outdated now, as
they no longer reflect the latest components and patterns we've
developed together through iteration. Since I am highly involved I can
adapt to this on the fly, but for someone coming at the mockups new it
can be a problem.

* The mockups can have obvious problems. Sometimes the designer doing
the mockup didn't quite understand what's going on in the KCM, or they
missed some important piece of the puzzle. So I can't just implement it
as-is, I need to provide feedback to the VDG and and explain and pose
them the challenge. They usually then produce new mockups that take this
feedback into account, and it's still a productivity win for my side of
things because I don't need to fiddle with mockups, and because more
people generate more ideas between them.

* In general I find that the VDG pulls me into directions I wouldn't
have gone in myself (e.g. due to "this would be annoying to code"
lazyness or having a biased tech perspective on the UI). I also find
that the VDG wouldn't be able to produce sensible UI without having
someone to explain the technology requirements. It's a mutual
push-and-pull and mutual course correction.

* The end result of this process is often better than what I would have
done all by myself, while requiring less of my own time and brainpower.
This means much higher utilization of myself and higher throughput. I
feel satified by the results in the end.

* I've realized that "making the VDG work well" is much less about
making the VDG "perfect" and producing exactly what you want at the push
of a button, but that "working well" is basically having a working
process like the one above.

* I've also realized that things are not easy from the VDG side of
things. For code contributors, there's a wealth of institutional
knowledge and experience to draw from. I can literally open up Hacker
News and peruse a dozen articles on how to engineer codebases and how to
work productively a day. Design teams in FOSS communities are a much
younger thing with much less in the way of provided ladders to climb.
They're also joining communities where code contributors have very low
levels of empathy for what it feels like when your opinion isn't law and
when it isn't taken for granted that you are gatekeeper to the
repository. There's a situation embarassingly close to the way that
white privilege works in the way code contributors are entrenched in
existing FOSS communities, and it's a barrier to true talent diversity.

Now from other developers I've gathered that their experience has been
different and much more frustrating. I believe it's due to several reasons:

* Not having been as lucky as me in having had the opportunity to work
with the VDG more regularly and experience a perspective change that
puts the process first. This manages my expectations for what I get out
of the VDG and what I need to on my end, and avoids frustration. It also
means I don't feel so bad when I say "no", because I get to have
confidence in what I bring to the table.

* It's very hard to have the experience I've had if you don't have the

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

[Nathaniel Graham]

ngraham added a comment.


  In D13274#273076 , @hein wrote:
  
  > This is not what the patch you like actually did. That patch disallowed 
//dropping// things outside the panel when it's locked, but it still, of 
course, allowed dragging them outside of the panel. It's basically the same as 
this, except that you need to unlock the panel to drop things on the desktop. I 
find that unnecessarily complicated and this works better.
  
  
  Oops, my mistake. I guess that's what I wished it did! Either way, thanks for 
this. Should make folks happy.

REPOSITORY
  R119 Plasma Desktop

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

[Powerdevil] [Bug 345618] Powerdevil crash from idle desktop.

[mthw0]

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

mthw0  changed:

   What|Removed |Added

 CC||jari...@hotmail.com
 Ever confirmed|0   |1
Version|5.2.0   |5.12.90
 Status|UNCONFIRMED |CONFIRMED
   Platform|unspecified |Archlinux Packages

--- Comment #14 from mthw0  ---
This recently happen to me too on Arch
Log:

Application: org_kde_powerdevil (org_kde_powerdevil), signal: Segmentation
fault
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f422a24d840 (LWP 4691))]

Thread 6 (Thread 0x7f4206d7b700 (LWP 4790)):
#0  0x7f42273aa934 in read () at /usr/lib/libc.so.6
#1  0x7f4221a89ed1 in  () at /usr/lib/libglib-2.0.so.0
#2  0x7f4221a43ff8 in g_main_context_check () at /usr/lib/libglib-2.0.so.0
#3  0x7f4221a444c6 in  () at /usr/lib/libglib-2.0.so.0
#4  0x7f4221a4463e in g_main_context_iteration () at
/usr/lib/libglib-2.0.so.0
#5  0x7f4227ccae64 in
QEventDispatcherGlib::processEvents(QFlags) ()
at /usr/lib/libQt5Core.so.5
#6  0x7f4227c7685c in
QEventLoop::exec(QFlags) () at
/usr/lib/libQt5Core.so.5
#7  0x7f4227abfac9 in QThread::exec() () at /usr/lib/libQt5Core.so.5
#8  0x7f4227ac9b95 in  () at /usr/lib/libQt5Core.so.5
#9  0x7f4224015075 in start_thread () at /usr/lib/libpthread.so.0
#10 0x7f42273b953f in clone () at /usr/lib/libc.so.6

Thread 5 (Thread 0x7f420757c700 (LWP 4789)):
#0  0x7f42273aeea9 in poll () at /usr/lib/libc.so.6
#1  0x7f4221a44523 in  () at /usr/lib/libglib-2.0.so.0
#2  0x7f4221a4463e in g_main_context_iteration () at
/usr/lib/libglib-2.0.so.0
#3  0x7f4227ccae64 in
QEventDispatcherGlib::processEvents(QFlags) ()
at /usr/lib/libQt5Core.so.5
#4  0x7f4227c7685c in
QEventLoop::exec(QFlags) () at
/usr/lib/libQt5Core.so.5
#5  0x7f4227abfac9 in QThread::exec() () at /usr/lib/libQt5Core.so.5
#6  0x7f4227ac9b95 in  () at /usr/lib/libQt5Core.so.5
#7  0x7f4224015075 in start_thread () at /usr/lib/libpthread.so.0
#8  0x7f42273b953f in clone () at /usr/lib/libc.so.6

Thread 4 (Thread 0x7f4215131700 (LWP 4749)):
#0  0x7f42273aeea9 in poll () at /usr/lib/libc.so.6
#1  0x7f4221a44523 in  () at /usr/lib/libglib-2.0.so.0
#2  0x7f4221a448e2 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#3  0x7f42160af348 in  () at /usr/lib/libgio-2.0.so.0
#4  0x7f4221a6ca2a in  () at /usr/lib/libglib-2.0.so.0
#5  0x7f4224015075 in start_thread () at /usr/lib/libpthread.so.0
#6  0x7f42273b953f in clone () at /usr/lib/libc.so.6

Thread 3 (Thread 0x7f4215932700 (LWP 4748)):
#0  0x7f42273aa934 in read () at /usr/lib/libc.so.6
#1  0x7f4221a89ed1 in  () at /usr/lib/libglib-2.0.so.0
#2  0x7f4221a43ff8 in g_main_context_check () at /usr/lib/libglib-2.0.so.0
#3  0x7f4221a444c6 in  () at /usr/lib/libglib-2.0.so.0
#4  0x7f4221a4463e in g_main_context_iteration () at
/usr/lib/libglib-2.0.so.0
#5  0x7f4221a44692 in  () at /usr/lib/libglib-2.0.so.0
#6  0x7f4221a6ca2a in  () at /usr/lib/libglib-2.0.so.0
#7  0x7f4224015075 in start_thread () at /usr/lib/libpthread.so.0
#8  0x7f42273b953f in clone () at /usr/lib/libc.so.6

Thread 2 (Thread 0x7f4217413700 (LWP 4742)):
#0  0x7f42273aa934 in read () at /usr/lib/libc.so.6
#1  0x7f4221a89ed1 in  () at /usr/lib/libglib-2.0.so.0
#2  0x7f4221a43ff8 in g_main_context_check () at /usr/lib/libglib-2.0.so.0
#3  0x7f4221a444c6 in  () at /usr/lib/libglib-2.0.so.0
#4  0x7f4221a4463e in g_main_context_iteration () at
/usr/lib/libglib-2.0.so.0
#5  0x7f4227ccae64 in
QEventDispatcherGlib::processEvents(QFlags) ()
at /usr/lib/libQt5Core.so.5
#6  0x7f4227c7685c in
QEventLoop::exec(QFlags) () at
/usr/lib/libQt5Core.so.5
#7  0x7f4227abfac9 in QThread::exec() () at /usr/lib/libQt5Core.so.5
#8  0x7f422811a976 in  () at /usr/lib/libQt5DBus.so.5
#9  0x7f4227ac9b95 in  () at /usr/lib/libQt5Core.so.5
#10 0x7f4224015075 in start_thread () at /usr/lib/libpthread.so.0
#11 0x7f42273b953f in clone () at /usr/lib/libc.so.6

Thread 1 (Thread 0x7f422a24d840 (LWP 4691)):
[KCrash Handler]
#6  0x7f4229c4b2ff in PowerDevil::Core::onResumingFromIdle() () at
/usr/lib/libpowerdevilcore.so.2
#7  0x7f4229c85996 in  () at /usr/lib/libpowerdevilcore.so.2
#8  0x7f4227ca1a0c in QMetaObject::activate(QObject*, int, int, void**) ()
at /usr/lib/libQt5Core.so.5
#9  0x7f422617d44d in  () at /usr/lib/libKF5IdleTime.so.5
#10 0x7f4227ca1a0c in QMetaObject::activate(QObject*, int, int, void**) ()
at /usr/lib/libQt5Core.so.5
#11 0x7f4227ca1b60 in QMetaObject::activate(QObject*, int, int, void**) ()
at /usr/lib/libQt5Core.so.5
#12 0x7f421798a1c8 in ffi_call_unix64 () at /usr/lib/libffi.so.6
#13 0x7f4217989c2a in ffi_call () at 

D13277: Turn off the extended resize handle/black triangle when there are no borders

[Roman Gilg]

romangg added a comment.


  In D13277#273061 , 
@hpereiradacosta wrote:
  
  > Now, no there is no reason not to turn it off by default, except that it 
will piss people relying on it (and now they will have to look for the option 
for turning it on again).
  
  
  That's not a good reason against changing a default. Otherwise we could never 
change one.
  
  > On the other hand I have seen no good reason, not to keep it on by default 
either. (might have missed them though).
  
  A good reason to remove this handle is that it paints over application 
content. Although it's only a very small area it does cover for example quite a 
large area of the lower scroll bar button in Chrome:
  F5888233: Screenshot_20180603_180754.png 

  In general indiscriminatorily changing client content presentation is bad 
practice, therefore I would even remove the option for the handle entirely or 
disallow it on a KWin level. Maybe it's this way already in the Wayland session 
(didn't test it there).
  
  > "this is ugly" (a word which I hear more and more these days and really 
come to dislike).
  
  You are right, that just saying something looks ugly is not a sufficient 
reasoning for a design change. But from what I've seen in the infamous "No 
window borders" task, which you were probably hinting at, the VDG also brought 
forward more sophisticated arguments in general. Besides that several devs 
chimed in saying that they change to "No Borders" all the time because they 
like it more. I for one never changed, because I don't care about such small 
details in the design. But having the borders removed now for testing purposes, 
I have to say it does look nice and I do think it leads to a better overall 
look of our default desktop (at least as long as the shadows are on, without 
them it's difficult to know where a window begins and where it ends -> that 
issue should be discussed in the task, but it's only a real problem on X where 
compositing can be turned off).
  
  > I am tired of arguing.
  
  Why do these discussions tire you? Our design can't stand still forever. If 
it's because the VDG proposed design changes somewhat hastily and without a 
grand concept behind them in the first half of this year: I agree. But look 
where we were coming from: the VDG was in complete disarray at the end of last 
year providing only minimal output. So we started at an absolute low point at 
the beginning of the year but I would say mostly thanks to the work of a few 
individuals, to whom I definitely count Nate, the VDG organisation and work 
output already got definitely better. And it will hopefully get substantially 
better when we can work out the remaining tasks of our HIG project, in 
particular T7983 . I wholeheartedly invite 
you to contribute to it with your experience as Breeze maintainer.
  
  There are other organisational measures, that could be discussed to improve 
the internal structure of the VDG and their cooperation with us devs, but for 
now I'm already very happy with the current progress.

REPOSITORY
  R31 Breeze

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

To: ngraham, #vdg, #breeze, #plasma, abetts, romangg
Cc: hpereiradacosta, romangg, plasma-devel, ragreen, Pitel, ZrenBot, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

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

[Eike Hein]

This revision was automatically updated to reflect the committed changes.
Closed by commit R119:c801276a593c: Make drags from the Task Manager less prone 
to disaster (authored by hein).

REPOSITORY
  R119 Plasma Desktop

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13274?vs=35370=35464

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

AFFECTED FILES
  applets/taskmanager/plugin/draghelper.cpp
  containments/desktop/package/contents/ui/code/FolderTools.js
  containments/desktop/plugins/folder/foldermodel.cpp

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

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

[Eike Hein]

hein added a comment.


  Agreed on master-only.
  
  > The fact that TM entries are draggable outside their panel in the first 
place is a bit odd in many contexts because most of the time you're going to be 
looking at apps, not your desktop, and there's nothing you would actually want 
to or be able to drag them to.
  
  I don't think this is odd at all. It's how desktop UIs work. I can also drag 
tabs from Firefox outside of Firefox, but I can't just drop them everywhere. 
Drags are globally modal in some sense, as are, say, context menus. There's no 
concept of "you can only drag within this area", generally, unless you go for 
cursor confinement, which has a host of other downsides.
  
  It works the same in other desktop operating systems, e.g. in the Mac OS dock.
  
  > I kind of preferred one of the original patches from way back yonder that 
only made TM entries draggable outside their panel when widgets were unlocked 
(D8564 : Disallow drop of task manager icons 
outside of plasmoid when widgets are locked).
  
  This is not what the patch you like actually did. That patch disallowed 
//dropping// things outside the panel when it's locked, but it still, of 
course, allowed dragging them outside of the panel. It's basically the same as 
this, except that you need to unlock the panel to drop things on the desktop. I 
find that unnecessarily complicated and this works better.

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

D13275: Teach ContainmentInterface::processMimeData how to handle Task Manager drops

[Eike Hein]

hein updated this revision to Diff 35463.
hein added a comment.


  Fix last minute build error.

REPOSITORY
  R242 Plasma Framework (Library)

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13275?vs=35371=35463

BRANCH
  master

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

AFFECTED FILES
  src/scriptengines/qml/plasmoid/containmentinterface.cpp

To: hein, davidedmundson, Zren, mart
Cc: ngraham, zzag, kde-frameworks-devel, plasma-devel, michaelh, bruns

D13277: Turn off the extended resize handle/black triangle when there are no borders

[Nathaniel Graham]

ngraham closed this revision.

REPOSITORY
  R31 Breeze

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

To: ngraham, #vdg, #breeze, #plasma, abetts, romangg
Cc: hpereiradacosta, romangg, plasma-devel, ragreen, Pitel, ZrenBot, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D13277: Turn off the extended resize handle/black triangle when there are no borders

[Hugo Pereira Da Costa]

hpereiradacosta added a comment.


  Long time ago, you could not resize windows from outside the window area. So 
when switching to no border, the only way you could resize a window was: the 
titlebar, keyboard shortcuts, and this handle. (which provided a reasonably 
large hit area at the bottom of the windw.
  That's why it was on by default. 
  Now, no there is no reason not to turn it off by default, except that it will 
piss people relying on it (and now they will have to look for the option for 
turning it on again).
  On the other hand I have seen no good reason, not to keep it on by default 
either. (might have missed them though). except from "this is ugly" (a word 
which I hear more and more these days and really come to dislike).
  On the section of devising a general rule by the example, I for one use this 
handle systematically to resize my borderless konsoles. got used to it, will 
turn it on systematically if the default is change.
  
  Feel free to commit. I am tired of arguing.

REPOSITORY
  R31 Breeze

BRANCH
  turn-off-black-triangle (branched from master)

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

To: ngraham, #vdg, #breeze, #plasma, abetts, romangg
Cc: hpereiradacosta, romangg, plasma-devel, ragreen, Pitel, ZrenBot, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D13277: Turn off the extended resize handle/black triangle when there are no borders

[Nathaniel Graham]

ngraham added a subscriber: hpereiradacosta.
ngraham added a comment.


  Same here, I always turn it off too. Of course since this is a Breeze change, 
I'll want to make sure @hpereiradacosta is okay with it.

REPOSITORY
  R31 Breeze

BRANCH
  turn-off-black-triangle (branched from master)

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

To: ngraham, #vdg, #breeze, #plasma, abetts, romangg
Cc: hpereiradacosta, romangg, plasma-devel, ragreen, Pitel, ZrenBot, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D13277: Turn off the extended resize handle/black triangle when there are no borders

[Roman Gilg]

romangg accepted this revision.
romangg added a comment.


  I think this should land independently of the other diffs. I've always used 
the Normal border size in the past, but now trying out "No Borders" with my 
patch I don't see the reason for painting this handle. Is there any reason to 
keep this default as it is?

REPOSITORY
  R31 Breeze

BRANCH
  turn-off-black-triangle (branched from master)

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

To: ngraham, #vdg, #breeze, #plasma, abetts, romangg
Cc: romangg, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

Re: Stepping down as maintainer

[Martin Flöser]

Am 2018-06-02 13:43, schrieb 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".


our experiences seem to differ here.


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.


What I considered as my most important job as maintainer was saying 
"no". If a change is wrong or against the product vision one needs to be 
able to say no. And there is nothing bad about that. It's the job of the 
maintainer to ensure the product is in good shape and goes into the 
right direction. If I as maintainer see that there could be a better 
solution or a proposed solution has side effects the author cannot know 
about it's my duty to say no. No matter whether it's a new contributor, 
the VDG or a dev having been around for 20 years.


What a maintainer should not say no to are ideas. In fact the maintainer 
should help moving ideas into the right direction, so that they could be 
added to the product. In that sense I think it is important to have the 
maintainer a gate keeper for the code side, but not for the idea side.


If we work like that I think this would be satisfying for all sides. To 
take the example of the no border change. I don't mind the VDG to want 
to improve the area. If they present the idea on "we want Kirigami apps 
look great", we can work on that. If instead a change is presented which 
is flipping a default on the code side, which doesn't make sense from 
the product perspective, my job as the gate keeper kicks in and I need 
to say no. For the overall product KWin I think this change is wrong. I 
think there are solutions which can result in satisfying both, Roman's 
patch is a step into that direction for example.


So the problem I see here is not that design and code teams clash. The 
problem is in my opinion that the design team presented technical 
solutions without consulting the experts.


Personally my opinion is that the VDG does not even want to change the 
borders. It's a hack around the problem. Kirigami apps seam not to be 
designed with decorations around them. That's fine, but changing the 
default as a hack is the wrong solution. Like what Hugo said we need to 
fix Kirigami instead of changing the default. There are multiple ways to 
do that. One option would certainly be client side decorations. And 
that's also fine. If that's what the VDG wants it could be implemented 
in a sane and working way. What I think is that they did not even 
consider that option. But that's where the expertise of the maintainer 
comes in. He is the one with the best technical understanding of the 
problem and the solution.




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?


Sorry about that. Maybe it's not the place to discuss that. I only 
wanted to explain why I lost motivation.


Cheers
Martin

Re: Stepping down as maintainer

[Martin Flöser]

Am 2018-06-02 16:15, schrieb 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.


For the time being I try to continue to go through the bugs.



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


I'm sure as well :-)

Cheers
Martin

Re: Stepping down as maintainer

[Martin Flöser]

Am 2018-06-02 10:59, schrieb 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.


No, that decision is final. It's not that I decided yesterday, but it's 
something I have been thinking about more and more often over the last 
year. Especially over the last months I got more and more frustrated and 
not motivated when going through reviews. In too many reviews I said no. 
I don't want to be the one guy who is against everything. In such a 
situation it's better to step down as maintainer and enjoy coding.



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.


I'm still around. Just ping me or add me to the review. I'll try to get 
phabricator notifications working for me by removing myself from the 
groups.




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?


As said the decision to not be maintainer any more is final. I'll be 
around to help and give advice, also to code, but not to maintain.


Cheers
Martin

D13292: Centre align SystemLoadViewer headers

[David Edmundson]

davidedmundson added a comment.


  Before: See bug report
  
  After: F5887210: Screenshot_20180603_083605.png 


REPOSITORY
  R114 Plasma Addons

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

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

D13292: Centre align SystemLoadViewer headers

[David Edmundson]

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

REVISION SUMMARY
  BUG: 394952

TEST PLAN
  Looked at it

REPOSITORY
  R114 Plasma Addons

BRANCH
  master

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

AFFECTED FILES
  applets/systemloadviewer/package/contents/ui/SystemLoadViewer.qml

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

D13275: Teach ContainmentInterface::processMimeData how to handle Task Manager drops

[Eike Hein]

hein created this revision.
hein added reviewers: davidedmundson, Zren, mart.
Restricted Application added a project: Frameworks.
Restricted Application added a subscriber: kde-frameworks-devel.
hein requested review of this revision.

REVISION SUMMARY
  To explicitly confine Task Manager drops to Plasma and avoid accidental
  drops on other apps, D13274  makes it 
store task launcher URLs in a special
  internal MIME type instead of the generic text/url one. This change to
  processMimeData() adds the necessary conversion back.

REPOSITORY
  R242 Plasma Framework (Library)

BRANCH
  master

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

AFFECTED FILES
  src/scriptengines/qml/plasmoid/containmentinterface.cpp

To: hein, davidedmundson, Zren, mart
Cc: kde-frameworks-devel, plasma-devel, michaelh, ngraham, bruns

D13277: Turn off the extended resize handle/black triangle when there are no borders

[Nathaniel Graham]

ngraham created this revision.
ngraham added reviewers: VDG, Breeze, Plasma.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.
ngraham requested review of this revision.

REVISION SUMMARY
  As discussed and agreed to in T8707: Window borders 
, turn off the black triangle that's 
currently drawn by default when windows are drawn with "No Borders"

TEST PLAN
  - Tested on a new user: no black triangle when KWin's border setting is "No 
Borders"
  - Tested on an existing user who had `DrawSizeGrip=false` in their `breezerc` 
file: no change
  - Tested on an existing user with who had `DrawSizeGrip=false` in their 
`breezerc` file and then turned it on in System Settings: black triangle 
appears as expected
  - With the black triangle on, reset to default settings: works as expected

REPOSITORY
  R31 Breeze

BRANCH
  turn-off-black-triangle (branched from master)

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

AFFECTED FILES
  kdecoration/breezesettingsdata.kcfg

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

D13192: Implement a triangle filter for mouse events on the Kickoff tabbar

[Eike Hein]

This revision was automatically updated to reflect the committed changes.
Closed by commit R119:62f92fd822ef: Implement a triangle filter for mouse 
events on the Kickoff tabbar (authored by hein).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D13192?vs=35194=35367#toc

REPOSITORY
  R119 Plasma Desktop

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13192?vs=35194=35367

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

AFFECTED FILES
  applets/kickoff/package/contents/ui/FullRepresentation.qml
  applets/kickoff/package/contents/ui/KickoffButton.qml

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

D13273: Fix Recent Applications sorting in Kicker and Dashboard.

[Eike Hein]

This revision was automatically updated to reflect the committed changes.
Closed by commit R119:eda4d2645fa8: Fix Recent Applications sorting in Kicker 
and Dashboard. (authored by hein).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D13273?vs=35360=35368#toc

REPOSITORY
  R119 Plasma Desktop

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13273?vs=35360=35368

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

AFFECTED FILES
  applets/kicker/plugin/recentusagemodel.cpp
  applets/kicker/plugin/recentusagemodel.h

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

Re: Broken Plasma 5.13 branch force-pushed.

[James Daniel Smith]

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

--  Forwarded Message  --
Hello,

On 25th following commit was pushed to plasma-desktop repo,

commit 34106f5dbff824b0c9903cef3b20244e0971
Author: James D. Smith 
Date:   Fri May 25 19:42:40 2018 -0600

And it was instead of cherry-picking into 5.12/5.13 branch or instead of
pushing in 5.12 branch and then merging into 5.13/master it was pushed
as 5.13 and 5.12

(git push origin HEAD:5.1{2,3}) or similar command..

Which badly broke the history of 5.12 and 5.13 branch, to fix this
following actions were taken,

- Lock repository down for normal developers
- Reset master to 6229570c3da21072fdb887e585a9b68d9bcaf11e
- Reset Plasma/5.13 to ea5199a751871863bcf599f1ce2517c476212223
- Reset Plasma/5.12 to f7516196cfa49904a4b9daf337090c8f2c78ab20
- Blacklist commit 34106f5dbff824b0c9903cef3b20244e0971
- Restore normal developer access
- Add extra commits on top of Plasma/5.12 , Plasma/5.13 and master
  branch

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

Please push the missing commits to branches but not the
34106f5dbff824b0c9903cef3b20244e0971 , please re-do that commit
instead to give it different hash and then merge it upto master branch.

Also due to force-push, you might have to re-clone plasma-desktop.

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
-

D13255: Make dependency on KF5NetworkManagerQt optional

[Ivan Čukić]

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


  - Would rather have a separate NetworkManager wrapper class implementation (a 
dummy implementation for when NM is disabled) than this.
  - Also, instead of a cmake flag, it is more common to find_package and define 
the flag depending on whether it was found or not.
  - What about the configuration UI?

REPOSITORY
  R845 Plasma Vault

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

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

Re: QtCreator with Kirigami for Subsurface

[jani]

> El 28 may 2018, a las 11:03, Marco Martin  escribió:
> 
> On Mon, May 28, 2018 at 10:52 AM Marco Martin  wrote:
> 
> Hi,
> unfortunately Qtcreator tends to be really picky with any 3rd party qml
> module...
> i think you need to have the file plugins.qmltypes somewhere where
> qtcreator understands it (i don't know if is possible for plugins that are
> shipped internally in the project like subsurface does)
> perhaps yoy could try to build and install kirigami with its own cmake as a
> plugin.. and install it right into the qt release that qtcreator is using,
> that should fix at least autocompletion, not sure wether is enough to make
> it available in the designer

Hi 

Thanks for your answer. I actually did exactly as you suggest. Ran make, make 
and make install in
Kirigami directory. The installs to /usr/local/lib/qml/org/kde/kirigami.2 and I 
copied it into the Qt install set.

Your idea with plugin.qmltypes could be the answer, that was not part of 
/usr/local/lib/qml/org/kde/kirigami.2
I will experiment a bit and see what I come up with.

rgds
Jan I.
> 
> --
> Marco Martin
> On Mon, May 28, 2018 at 10:42 AM  wrote:
> 
>> Hi
> 
>> My name is Jan Iversen, I am working on the Subsurface project to make
> subsurface-mobile have more of the
>> Features currently only available in our desktop version. This of course
> means using more kirigami and QtQuick.2
> 
>> I would like to use Qt Creator to do big parts of the kirigami qml
> design, instead of “guessing” the result, but it doesn’t work.
> 
>> Currently when I open a qml document, the plugin line:
> 
>> import org.kde.kirigami 2.2 as Kirigami
> 
>> Is accepted with no errors
> 
>> But all Kirigami specific lines like e.g.
> 
>> Kirigami.ScrollablePage {
> 
>> Have the error “Unknown component (M00)
> 
>> I work on a Mac (primarily doing iOS work), and have generated the plugin
> and moved org/kde/kirigami to the Qt qml directory,
>> As well as copied the dylib files to Qt Creator App Frameworks and
> plugins/designer
> 
>> When I start Qt Creator I can see in “About plugins” that it has not
> found a designer plugin.
> 
>> I have also tried to start Qt Creator from the command line with -load
> kirigamiplugin, but I get an error message saying it does not exist.
> 
>> Can you please advice, how I can design the kirigami/qml files using
> QtCreator.
> 
>> A big thank for your efforts with kirigami and another thanks for a
> hopefully positive answer.
>> rgds
>> Jan I.
> 
>> Ps. I am not subscribed to your ML, so please CC me on responses.