Re: Review Request 125248: Display name of process which blocks umount / eject

[Martin Klapetek]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125248/#review85469
---



dataengines/devicenotifications/ksolidnotify.cpp (line 122)


This should be a private method rather than a static method

(and also const QString& devicePath --> const QString )

...I'm thinking that maybe this method should become part of 
Solid::StorageAccess itself? Though I'm not the maintainer so I dunno but it 
seems it would be useful there



dataengines/devicenotifications/ksolidnotify.cpp (lines 135 - 136)


Our codestyle requires braces around ifs



dataengines/devicenotifications/ksolidnotify.cpp (lines 149 - 150)


{}s

(same in the other block)


- Martin Klapetek


On Sept. 15, 2015, 11:41 p.m., Igor Poboiko wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125248/
> ---
> 
> (Updated Sept. 15, 2015, 11:41 p.m.)
> 
> 
> Review request for Plasma and Solid.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> An attempt to implement feature from [bug 
> 96107](https://bugs.kde.org/show_bug.cgi?id=96107) (see summary).
> 
> On umount/eject error it runs "lsof" executable, gets PIDs of blocking 
> processes and obtains names of processes via KSysGuard::Process machinery. 
> Finally it appends obtained information to error message which is shown in 
> tooltip of Device Notifier applet.
> 
> 
> Diffs
> -
> 
>   dataengines/devicenotifications/CMakeLists.txt 3f7fd83 
>   dataengines/devicenotifications/ksolidnotify.cpp 35d49d6 
> 
> Diff: https://git.reviewboard.kde.org/r/125248/diff/
> 
> 
> Testing
> ---
> 
> Tested unmount on busy device with several processes blocking it. Did not 
> test eject, since I have no optical disc drive :(
> 
> 
> File Attachments
> 
> 
> Applet with error message
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/09/15/3b1b64fc-abff-4633-9dca-621388edf086__snapshot11.png
> 
> 
> Thanks,
> 
> Igor Poboiko
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 125248: Display name of process which blocks umount / eject

[Xuetian Weng]

> On Sept. 15, 2015, 10:41 p.m., Martin Klapetek wrote:
> > dataengines/devicenotifications/ksolidnotify.cpp, line 122
> > 
> >
> > This should be a private method rather than a static method
> > 
> > (and also const QString& devicePath --> const QString )
> > 
> > 
> > ...I'm thinking that maybe this method should become part of 
> > Solid::StorageAccess itself? Though I'm not the maintainer so I dunno but 
> > it seems it would be useful there

(Not a maintainer either :) ) I agree this should belong to solid, so we can 
have platform dependent solution for more easily. Similar feature is also 
implemented in gvfs.

Actually I'm a little bit surprise that gvfs also uses lsof command to do the 
same thing instead of parsing procfs. fuser may be an better alternative POSIX 
choice. (Make sure use the posix compat option if you want to use fuser 
http://www.unix.com/man-page/posix/1posix/fuser/ , if you run it manually 
stderr will make the output confusing, run fuser -c / 2>/dev/null to get the 
pid only output.)


- Xuetian


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125248/#review85469
---


On Sept. 15, 2015, 9:41 p.m., Igor Poboiko wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125248/
> ---
> 
> (Updated Sept. 15, 2015, 9:41 p.m.)
> 
> 
> Review request for Plasma and Solid.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> An attempt to implement feature from [bug 
> 96107](https://bugs.kde.org/show_bug.cgi?id=96107) (see summary).
> 
> On umount/eject error it runs "lsof" executable, gets PIDs of blocking 
> processes and obtains names of processes via KSysGuard::Process machinery. 
> Finally it appends obtained information to error message which is shown in 
> tooltip of Device Notifier applet.
> 
> 
> Diffs
> -
> 
>   dataengines/devicenotifications/CMakeLists.txt 3f7fd83 
>   dataengines/devicenotifications/ksolidnotify.cpp 35d49d6 
> 
> Diff: https://git.reviewboard.kde.org/r/125248/diff/
> 
> 
> Testing
> ---
> 
> Tested unmount on busy device with several processes blocking it. Did not 
> test eject, since I have no optical disc drive :(
> 
> 
> File Attachments
> 
> 
> Applet with error message
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/09/15/3b1b64fc-abff-4633-9dca-621388edf086__snapshot11.png
> 
> 
> Thanks,
> 
> Igor Poboiko
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

How to speed up QML for KDE5 without QML compiler

[Leslie Zhai]

Hi great Qt and KDE developers,

I like QML, it is high speed development language, easy to create candy 
UI and not difficult to debug. KDE4 began to use it in some projects, 
for example, KScreen`s kcm module, it used QML to take place of 
traditional QWidget. and KDE5, it is full of QML, for example, kwin`s 
tabbox, plasma-desktop and plasma-workspace`s applet, sddm, etc.


For a new PC,  there is no sharp difference between QML and QWidget, but 
in a very very old PC, how old? about 7 years ago, QML is very slow! and 
it needs to close all effects for KDE5, even that when clicked, for 
example, calendar applet, it hang about 3+ seconds to showPopup.


There is commercial QML compiler, a very small example tried to use it 
https://github.com/AOSC-Dev/AOSC-VersionHelper2
But is it suitable for huge projects just like KDE5 if bought a 
commercial license? because not all KF5 components follow the Qt Quick 
Compiler`s resource.qrc way, so is it able to compile? for example, 
kickoff applet (the start menu of KDE5).


--
Regards,
Leslie Zhai - a KDE developer

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 125248: Display name of process which blocks umount / eject

[Xuetian Weng]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125248/#review85474
---



dataengines/devicenotifications/ksolidnotify.cpp (line 39)


This is unused.



dataengines/devicenotifications/ksolidnotify.cpp (line 156)


", " should also in i18n().



dataengines/devicenotifications/ksolidnotify.cpp (line 192)


This too.


- Xuetian Weng


On Sept. 15, 2015, 9:41 p.m., Igor Poboiko wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125248/
> ---
> 
> (Updated Sept. 15, 2015, 9:41 p.m.)
> 
> 
> Review request for Plasma and Solid.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> An attempt to implement feature from [bug 
> 96107](https://bugs.kde.org/show_bug.cgi?id=96107) (see summary).
> 
> On umount/eject error it runs "lsof" executable, gets PIDs of blocking 
> processes and obtains names of processes via KSysGuard::Process machinery. 
> Finally it appends obtained information to error message which is shown in 
> tooltip of Device Notifier applet.
> 
> 
> Diffs
> -
> 
>   dataengines/devicenotifications/CMakeLists.txt 3f7fd83 
>   dataengines/devicenotifications/ksolidnotify.cpp 35d49d6 
> 
> Diff: https://git.reviewboard.kde.org/r/125248/diff/
> 
> 
> Testing
> ---
> 
> Tested unmount on busy device with several processes blocking it. Did not 
> test eject, since I have no optical disc drive :(
> 
> 
> File Attachments
> 
> 
> Applet with error message
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/09/15/3b1b64fc-abff-4633-9dca-621388edf086__snapshot11.png
> 
> 
> Thanks,
> 
> Igor Poboiko
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 125248: Display name of process which blocks umount / eject

[Xuetian Weng]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125248/#review85473
---



dataengines/devicenotifications/ksolidnotify.cpp (line 131)


I'd prefer to make it async.


- Xuetian Weng


On Sept. 15, 2015, 9:41 p.m., Igor Poboiko wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125248/
> ---
> 
> (Updated Sept. 15, 2015, 9:41 p.m.)
> 
> 
> Review request for Plasma and Solid.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> An attempt to implement feature from [bug 
> 96107](https://bugs.kde.org/show_bug.cgi?id=96107) (see summary).
> 
> On umount/eject error it runs "lsof" executable, gets PIDs of blocking 
> processes and obtains names of processes via KSysGuard::Process machinery. 
> Finally it appends obtained information to error message which is shown in 
> tooltip of Device Notifier applet.
> 
> 
> Diffs
> -
> 
>   dataengines/devicenotifications/CMakeLists.txt 3f7fd83 
>   dataengines/devicenotifications/ksolidnotify.cpp 35d49d6 
> 
> Diff: https://git.reviewboard.kde.org/r/125248/diff/
> 
> 
> Testing
> ---
> 
> Tested unmount on busy device with several processes blocking it. Did not 
> test eject, since I have no optical disc drive :(
> 
> 
> File Attachments
> 
> 
> Applet with error message
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/09/15/3b1b64fc-abff-4633-9dca-621388edf086__snapshot11.png
> 
> 
> Thanks,
> 
> Igor Poboiko
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Adding further modules to api.kde.org

[Martin Graesslin]

Hi Allen,

is there anything I can do to help get the documentation updated? I want to 
include KWayland in inqlude (patch is prepared) and I find a little bit 
embarrassing for KDE to have the api docs to point to 
http://kde.martin-graesslin.com/kwayland/index.html

Cheers
Martin

On Thursday, September 10, 2015 4:06:31 PM CEST Allen Winter wrote:
> On Thursday, September 10, 2015 01:55:21 PM Jeremy Whiting wrote:
> > Allen,
> > 
> > Those are both KDE4 versions of workspace stuff. I don't see any place
> > where kf5 versions are.
> 
> oh. sorry I misunderstood the problem.
> 
> > On Thu, Sep 10, 2015 at 1:50 PM, Allen Winter  wrote:
> > > On Thursday, September 10, 2015 10:57:10 AM Martin Graesslin wrote:
> > >> Hi all,
> > >> 
> > >> back in KDE4 days the workspace libraries were listed on api.kde.org
> > >> [1]. But for the current version we don't have any API docs available.
> > >> The section "Other KDE Software" [2] lists KDE Support, KDE Extragear
> > >> and Playground but apparently nothing from what used to be KDE SC.
> > >> 
> > >> Does anybody know how I can get our KDE Workspaces listed there again?
> > >> I'm in particular interested in getting KWayland API documentation
> > >> published.
> > >> 
> > >> If nobody knows: does anyone know who needs to be poked.
> > > 
> > > http://api.kde.org/4.x-api/workspace-apidocs/ exists
> > > The KDE SC stuff is shown under "KDE4 Versions"
> > > http://api.kde.org/history4.php
> > > 
> > > I do notice that under the various KDE 4.foo tables we don't have a
> > > workspace entry we have kde-workspace, but not workspace.  seems like
> > > kde-workspace and workspace are similar.
> > > 
> > > I'm not sure there's anything to fix.
> > > 
> > > -Allen


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 125226: move EventForge from the desktop containment

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125226/
---

(Updated Sept. 15, 2015, 5:30 p.m.)


Review request for KDE Frameworks, Plasma and Eike Hein.


Changes
---

RFC: this version impements a similar thing in MouseEventListener, that would 
be done automatically, without API.
there may be side effects, but it may make sense if a mouseeventlistener 
manages a pressandhold, it cancels all the events half managed by the children 
so far


Repository: kdeclarative


Description
---

EventForge can cancel the half-managed events of child items
in order to implement the move of them with press and hold,
not having the parent and the children battling for the same
press-move-release event sequence.

API-wise I think it's fine, apart perhaps the EventForge class name
(perhaps MouseEventGrabber is less technically correct, but still more clear?)


Diffs (updated)
-

  src/qmlcontrols/kquickcontrolsaddons/mouseeventlistener.h a62efb7 
  src/qmlcontrols/kquickcontrolsaddons/mouseeventlistener.cpp d3321a3 

Diff: https://git.reviewboard.kde.org/r/125226/diff/


Testing
---


Thanks,

Marco Martin

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 125226: move EventForge from the desktop containment

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125226/
---

(Updated Sept. 15, 2015, 5:32 p.m.)


Review request for KDE Frameworks, Plasma and Eike Hein.


Changes
---

fix the logic


Repository: kdeclarative


Description
---

EventForge can cancel the half-managed events of child items
in order to implement the move of them with press and hold,
not having the parent and the children battling for the same
press-move-release event sequence.

API-wise I think it's fine, apart perhaps the EventForge class name
(perhaps MouseEventGrabber is less technically correct, but still more clear?)


Diffs (updated)
-

  src/qmlcontrols/kquickcontrolsaddons/mouseeventlistener.h a62efb7 
  src/qmlcontrols/kquickcontrolsaddons/mouseeventlistener.cpp d3321a3 

Diff: https://git.reviewboard.kde.org/r/125226/diff/


Testing
---


Thanks,

Marco Martin

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 125187: Stop requiring Frameworks 5.15

[Aleix Pol Gonzalez]

> On Sept. 14, 2015, 10:44 a.m., Martin Gräßlin wrote:
> > -2, a change for a month in the devel branch doesn't make much sense.
> 
> David Faure wrote:
> As you want. You're raising the bar for new contributors, who can't work 
> on your code using the latest KDE Frameworks release.
> 
> You and me might compile everything, but you'll get more contributors if 
> you let people work on workspace and apps using a released frameworks (for 
> which there are distro packages) than if you require them to compile 
> frameworks first. Just like we don't require Qt from git, we shouldn't 
> require KF5 from git, I thought this was the general agreement.
> 
> If you're worried about the ifdef, just use the two liner version of the 
> code forever, I was always a bit dubious about adding a method just for that 
> anyway.
> 
> Martin Gräßlin wrote:
> It's really not that uncommon to depend on latest frameworks in 
> workspace. It's common that I add things in KWindowSystem to make use of it 
> in KWin directly. Or lately I used lots of new functionalty from KGlobalAccel 
> directly.
> 
> Yes it raises the entry level, but it's also rather unlikely that we are 
> able to a policy forbidding depending on frameworks master without CI checks.
> 
> Sebastian Kügler wrote:
> Besides, these occasional devs can use the stable branch en then forward 
> port?
> 
> Marco Martin wrote:
> -2 from here as well for the same reasons
> 
> Ben Cooksley wrote:
> Please note that the CI system is shifting towards only allowing usage of 
> released products. We'll also be imposing a dependency prohibition between 
> Applications and Plasma so there will no longer be any ability to have 
> dependencies between the two.

@Ben: Really? Why? Where was this discussed?


- Aleix


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125187/#review85353
---


On Sept. 12, 2015, 11:38 a.m., Armin K. wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125187/
> ---
> 
> (Updated Sept. 12, 2015, 11:38 a.m.)
> 
> 
> Review request for Plasma and David Faure.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> KDesktopFile.readMimeTypes(); hasn't made it into Frameworks 5.14, causing 
> plasma-workspace git master to depend on yet unreleased version of KDE 
> Frameworks to build. David Faure has suggested to use fix like this one until 
> at least Frameworks 5.15 have been released.
> 
> I don't have commit access, so someone needs to commit this for me.
> 
> 
> Diffs
> -
> 
>   applets/icon/plugin/icon_p.cpp 97af67a 
> 
> Diff: https://git.reviewboard.kde.org/r/125187/diff/
> 
> 
> Testing
> ---
> 
> It builds.
> 
> 
> Thanks,
> 
> Armin K.
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 125235: Make sure the cancel and shutdown/logout button have the same size

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125235/#review85427
---

Ship it!


Ship It!

- Marco Martin


On Sept. 15, 2015, 8:49 a.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125235/
> ---
> 
> (Updated Sept. 15, 2015, 8:49 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> The RowLayout squeezed them, now we ensure we have a big enough button for 
> both actions.
> 
> 
> Diffs
> -
> 
>   lookandfeel/contents/components/LogoutScreen.qml 02296d5 
> 
> Diff: https://git.reviewboard.kde.org/r/125235/diff/
> 
> 
> Testing
> ---
> 
> Screenshot: http://i.imgur.com/G9rTHKB.png
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 125187: Stop requiring Frameworks 5.15

[Martin Gräßlin]

> On Sept. 14, 2015, 10:44 a.m., Martin Gräßlin wrote:
> > -2, a change for a month in the devel branch doesn't make much sense.
> 
> David Faure wrote:
> As you want. You're raising the bar for new contributors, who can't work 
> on your code using the latest KDE Frameworks release.
> 
> You and me might compile everything, but you'll get more contributors if 
> you let people work on workspace and apps using a released frameworks (for 
> which there are distro packages) than if you require them to compile 
> frameworks first. Just like we don't require Qt from git, we shouldn't 
> require KF5 from git, I thought this was the general agreement.
> 
> If you're worried about the ifdef, just use the two liner version of the 
> code forever, I was always a bit dubious about adding a method just for that 
> anyway.
> 
> Martin Gräßlin wrote:
> It's really not that uncommon to depend on latest frameworks in 
> workspace. It's common that I add things in KWindowSystem to make use of it 
> in KWin directly. Or lately I used lots of new functionalty from KGlobalAccel 
> directly.
> 
> Yes it raises the entry level, but it's also rather unlikely that we are 
> able to a policy forbidding depending on frameworks master without CI checks.
> 
> Sebastian Kügler wrote:
> Besides, these occasional devs can use the stable branch en then forward 
> port?
> 
> Marco Martin wrote:
> -2 from here as well for the same reasons
> 
> Ben Cooksley wrote:
> Please note that the CI system is shifting towards only allowing usage of 
> released products. We'll also be imposing a dependency prohibition between 
> Applications and Plasma so there will no longer be any ability to have 
> dependencies between the two.
> 
> Aleix Pol Gonzalez wrote:
> @Ben: Really? Why? Where was this discussed?

@Ben: where should libraries like kwayland and kdecoration go then? They do not 
fit requirements of frameworks but might be useable to applications (kwayland 
is a must have library for any wayland integration).


- Martin


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125187/#review85353
---


On Sept. 12, 2015, 11:38 a.m., Armin K. wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125187/
> ---
> 
> (Updated Sept. 12, 2015, 11:38 a.m.)
> 
> 
> Review request for Plasma and David Faure.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> KDesktopFile.readMimeTypes(); hasn't made it into Frameworks 5.14, causing 
> plasma-workspace git master to depend on yet unreleased version of KDE 
> Frameworks to build. David Faure has suggested to use fix like this one until 
> at least Frameworks 5.15 have been released.
> 
> I don't have commit access, so someone needs to commit this for me.
> 
> 
> Diffs
> -
> 
>   applets/icon/plugin/icon_p.cpp 97af67a 
> 
> Diff: https://git.reviewboard.kde.org/r/125187/diff/
> 
> 
> Testing
> ---
> 
> It builds.
> 
> 
> Thanks,
> 
> Armin K.
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 125226: move EventForge from the desktop containment

[Marco Martin]

On Sept. 15, 2015, 12:06 a.m., Marco Martin wrote:
> > This class feels like it's just working round Qt bugs?
> > 
> > Other than that if this is long-term useful, we should do sendPress(flags 
> > buttons, flags modifiers, x, y) not just whatever AppletAppearance happened 
> > to need (or make it part of makeGrab() if that's all it's for )
> 
> Marco Martin wrote:
> It can be said it work around Qt bugs, so yeah, not too happy it's needed.
> maybe to commit to it slightly less it could be put into the 
> plasma-workspace imports (as to say it can be used only in containments)
> But works around the very way how events are managed in Qt. once a child 
> accepted a press (and maybe some moves) it can't really be interrupted as two 
> items can't accept the same event. So this fakes it by sending fake events to 
> cancel the management cycle initiated by the child on mouyse press. don't 
> think there is really a way about it as is how Qt event management work (and 
> not only in qtquick)
> 
> Marco Martin wrote:
> an alternative API may be
> PressAndHoldManager {
> dragArea: dragAreaItem
> MouseArea {
> id: dragAreaItem
> MouseArea {
> id: itemToDrag
> }
> }
> }
> 
> not sure it it would really work

About putting it in workspace, would probably be a better idea, however this 
may end up being needed in random plasma mobile applications as seems press and 
hold may end up used a lot looking at the talks about higs


- Marco


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125226/#review85410
---


On Sept. 14, 2015, 5:17 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125226/
> ---
> 
> (Updated Sept. 14, 2015, 5:17 p.m.)
> 
> 
> Review request for KDE Frameworks, Plasma and Eike Hein.
> 
> 
> Repository: kdeclarative
> 
> 
> Description
> ---
> 
> EventForge can cancel the half-managed events of child items
> in order to implement the move of them with press and hold,
> not having the parent and the children battling for the same
> press-move-release event sequence.
> 
> API-wise I think it's fine, apart perhaps the EventForge class name
> (perhaps MouseEventGrabber is less technically correct, but still more clear?)
> 
> 
> Diffs
> -
> 
>   src/qmlcontrols/kquickcontrolsaddons/CMakeLists.txt 5b711e1 
>   src/qmlcontrols/kquickcontrolsaddons/eventforge.h PRE-CREATION 
>   src/qmlcontrols/kquickcontrolsaddons/eventforge.cpp PRE-CREATION 
>   src/qmlcontrols/kquickcontrolsaddons/kquickcontrolsaddonsplugin.cpp a33e03f 
> 
> Diff: https://git.reviewboard.kde.org/r/125226/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 125235: Make sure the cancel and shutdown/logout button have the same size

[Aleix Pol Gonzalez]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125235/
---

(Updated Sept. 15, 2015, 9:52 a.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma.


Changes
---

Submitted with commit 93bf81eea152e2b8261ac4a854207af448ed7c43 by Aleix Pol to 
branch Plasma/5.4.


Repository: plasma-workspace


Description
---

The RowLayout squeezed them, now we ensure we have a big enough button for both 
actions.


Diffs
-

  lookandfeel/contents/components/LogoutScreen.qml 02296d5 

Diff: https://git.reviewboard.kde.org/r/125235/diff/


Testing
---

Screenshot: http://i.imgur.com/G9rTHKB.png


Thanks,

Aleix Pol Gonzalez

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 125187: Stop requiring Frameworks 5.15

[Ben Cooksley]

> On Sept. 14, 2015, 8:44 a.m., Martin Gräßlin wrote:
> > -2, a change for a month in the devel branch doesn't make much sense.
> 
> David Faure wrote:
> As you want. You're raising the bar for new contributors, who can't work 
> on your code using the latest KDE Frameworks release.
> 
> You and me might compile everything, but you'll get more contributors if 
> you let people work on workspace and apps using a released frameworks (for 
> which there are distro packages) than if you require them to compile 
> frameworks first. Just like we don't require Qt from git, we shouldn't 
> require KF5 from git, I thought this was the general agreement.
> 
> If you're worried about the ifdef, just use the two liner version of the 
> code forever, I was always a bit dubious about adding a method just for that 
> anyway.
> 
> Martin Gräßlin wrote:
> It's really not that uncommon to depend on latest frameworks in 
> workspace. It's common that I add things in KWindowSystem to make use of it 
> in KWin directly. Or lately I used lots of new functionalty from KGlobalAccel 
> directly.
> 
> Yes it raises the entry level, but it's also rather unlikely that we are 
> able to a policy forbidding depending on frameworks master without CI checks.
> 
> Sebastian Kügler wrote:
> Besides, these occasional devs can use the stable branch en then forward 
> port?
> 
> Marco Martin wrote:
> -2 from here as well for the same reasons
> 
> Ben Cooksley wrote:
> Please note that the CI system is shifting towards only allowing usage of 
> released products. We'll also be imposing a dependency prohibition between 
> Applications and Plasma so there will no longer be any ability to have 
> dependencies between the two.
> 
> Aleix Pol Gonzalez wrote:
> @Ben: Really? Why? Where was this discussed?
> 
> Martin Gräßlin wrote:
> @Ben: where should libraries like kwayland and kdecoration go then? They 
> do not fit requirements of frameworks but might be useable to applications 
> (kwayland is a must have library for any wayland integration).

That has yet to be resolved. Likely another layer which will be released as 
needed by Applications / Plasma which sits in between Frameworks and them will 
be added I suspect. No binary compatibility commitments, same licensing rules 
as Applications / Plasma, just a logically separate product so it doesn't cause 
dependency problems. I don't expect too many libraries or runtime components to 
end up there (Dr Konqi might perhaps?).


- Ben


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125187/#review85353
---


On Sept. 12, 2015, 9:38 a.m., Armin K. wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125187/
> ---
> 
> (Updated Sept. 12, 2015, 9:38 a.m.)
> 
> 
> Review request for Plasma and David Faure.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> KDesktopFile.readMimeTypes(); hasn't made it into Frameworks 5.14, causing 
> plasma-workspace git master to depend on yet unreleased version of KDE 
> Frameworks to build. David Faure has suggested to use fix like this one until 
> at least Frameworks 5.15 have been released.
> 
> I don't have commit access, so someone needs to commit this for me.
> 
> 
> Diffs
> -
> 
>   applets/icon/plugin/icon_p.cpp 97af67a 
> 
> Diff: https://git.reviewboard.kde.org/r/125187/diff/
> 
> 
> Testing
> ---
> 
> It builds.
> 
> 
> Thanks,
> 
> Armin K.
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request 125234: [wayland] Add key repeat information

[Martin Gräßlin]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125234/
---

Review request for Plasma.


Repository: kinfocenter


Description
---

I needed a way to test whether KWin properly exports key repeat ;-)


Diffs
-

  Modules/base/info_wayland.cpp e27c18e358a6697ec3c919246ad56551ab933433 

Diff: https://git.reviewboard.kde.org/r/125234/diff/


Testing
---


File Attachments


Kinfocenter with key repeat information
  
https://git.reviewboard.kde.org/media/uploaded/files/2015/09/15/754e6b03-71ff-452f-89f3-b0e0237331b0__kwin_screenshot_bZ7878.png


Thanks,

Martin Gräßlin

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 125198: by default do not restore the previous session on next login

[Harald Sitter]

> On Sept. 12, 2015, 9:25 p.m., Kai Uwe Broulik wrote:
> > Same for me. +1 
> > OS X has a check box on the logout dialog, perhaps we could have something 
> > similar to make thmore discoverable
> 
> David Edmundson wrote:
> Oooh! I like that idea a lot. It can default to what the user last set it 
> to.

http://imgur.com/0rOaaDY

Mind you, if we use this to replace the KCM then we will be removing the 
"restore-saved-session" feature. I am not sure that is a thing we should do 
during the life time of plasma5 :P

Other option would be a checkbox which won't work because making the session 
management concept understandable requires more than 2 words in english so it'd 
be causing super long comboboxes/dropdowns in !english.


- Harald


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125198/#review85295
---


On Sept. 12, 2015, 3:37 p.m., Harald Sitter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125198/
> ---
> 
> (Updated Sept. 12, 2015, 3:37 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> As requested by the VDG.
> Rationale being that starting with an empty session all the time is
> substantially less aggressive than potentially starting a gazillion
> applications slowing down startup and greeting the user with a
> cluttered desktop.
> 
> 
> Diffs
> -
> 
>   ksmserver/main.cpp 4808a80081c3f4322c0d1b3223fc65bcbfeb26c1 
>   ksmserver/shutdown.cpp 636ae66fcce1d5c39fd697925b9094abc44e4808 
> 
> Diff: https://git.reviewboard.kde.org/r/125198/diff/
> 
> 
> Testing
> ---
> 
> installed. wiped ksmserverrc. multiple logins always result in an empty 
> session.
> 
> 
> Thanks,
> 
> Harald Sitter
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 125198: by default do not restore the previous session on next login

[Harald Sitter]

> On Sept. 14, 2015, 6:05 a.m., Martin Gräßlin wrote:
> > +1 - as a note: in openSUSE users were quite angry that we had broken 
> > session management, they won't be glad about the choice. My personal 
> > opinion is (as many probably known) that I would drop all session 
> > management support as I consider it as a relict from pre-suspend times.
> 
> Marco Martin wrote:
> I still tend to prefer it to suspend, starts things kindof where i was 
> but slightly more clean slate than suspend (maybe is also due that i still do 
> find suspend unreliable and horribly slow with 8 or more GB of ram).
> It's fine to disable it by default, but the thing I'm afraid is that it 
> may break again without being noticed, and i definitely want to keep it and 
> keep it working for the time being.
> 
> Harald Sitter wrote:
> Suspend to harddisk is sometimes weirdly broken. Suspend in general has 
> some hardware detection problems (see steamos suspend disabled because usb 
> devices do not get detected when coming out of suspend). At the same time as 
> I mentioned yesterday on IRC session restore often requires explicit support 
> to be implemented on an application level which also renders it part-defunct 
> depending on the applications one uses as the application will often just 
> come up with the default UI state which conceptually is not "restoring" but 
> "reopening". All in all both options are meh at times.
> 
> So, I'd argue that suspend should be the go-to choice for the "restore" 
> feature and we should demote session management as a "reopening"-only 
> feature. Specifically that means changing the name and advertising it in that 
> fashion which is line with what Kai suggested above as reopening is a much 
> more immediate choice you want to make on logout actions. This also means 
> that we'd consider it correct behavior if an application comes up in its 
> default UI state. If an application chooses to implement restore that is cool 
> as well but not required from a UX POV.
> 
> Marco Martin wrote:
> may make sense, i don't like much the layout, would be probably be better 
> on the same line of the button at the right of the screen (but then i fear 
> seeing that line of text in german :/)

yeah XD

Uri said that he'll redo the logout screen this week though, so perhaps there'd 
be a better spot for it afterwards.


- Harald


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125198/#review85343
---


On Sept. 12, 2015, 3:37 p.m., Harald Sitter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125198/
> ---
> 
> (Updated Sept. 12, 2015, 3:37 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> As requested by the VDG.
> Rationale being that starting with an empty session all the time is
> substantially less aggressive than potentially starting a gazillion
> applications slowing down startup and greeting the user with a
> cluttered desktop.
> 
> 
> Diffs
> -
> 
>   ksmserver/main.cpp 4808a80081c3f4322c0d1b3223fc65bcbfeb26c1 
>   ksmserver/shutdown.cpp 636ae66fcce1d5c39fd697925b9094abc44e4808 
> 
> Diff: https://git.reviewboard.kde.org/r/125198/diff/
> 
> 
> Testing
> ---
> 
> installed. wiped ksmserverrc. multiple logins always result in an empty 
> session.
> 
> 
> Thanks,
> 
> Harald Sitter
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 125187: Stop requiring Frameworks 5.15

[Ben Cooksley]

> On Sept. 14, 2015, 8:44 a.m., Martin Gräßlin wrote:
> > -2, a change for a month in the devel branch doesn't make much sense.
> 
> David Faure wrote:
> As you want. You're raising the bar for new contributors, who can't work 
> on your code using the latest KDE Frameworks release.
> 
> You and me might compile everything, but you'll get more contributors if 
> you let people work on workspace and apps using a released frameworks (for 
> which there are distro packages) than if you require them to compile 
> frameworks first. Just like we don't require Qt from git, we shouldn't 
> require KF5 from git, I thought this was the general agreement.
> 
> If you're worried about the ifdef, just use the two liner version of the 
> code forever, I was always a bit dubious about adding a method just for that 
> anyway.
> 
> Martin Gräßlin wrote:
> It's really not that uncommon to depend on latest frameworks in 
> workspace. It's common that I add things in KWindowSystem to make use of it 
> in KWin directly. Or lately I used lots of new functionalty from KGlobalAccel 
> directly.
> 
> Yes it raises the entry level, but it's also rather unlikely that we are 
> able to a policy forbidding depending on frameworks master without CI checks.
> 
> Sebastian Kügler wrote:
> Besides, these occasional devs can use the stable branch en then forward 
> port?
> 
> Marco Martin wrote:
> -2 from here as well for the same reasons

Please note that the CI system is shifting towards only allowing usage of 
released products. We'll also be imposing a dependency prohibition between 
Applications and Plasma so there will no longer be any ability to have 
dependencies between the two.


- Ben


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125187/#review85353
---


On Sept. 12, 2015, 9:38 a.m., Armin K. wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125187/
> ---
> 
> (Updated Sept. 12, 2015, 9:38 a.m.)
> 
> 
> Review request for Plasma and David Faure.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> KDesktopFile.readMimeTypes(); hasn't made it into Frameworks 5.14, causing 
> plasma-workspace git master to depend on yet unreleased version of KDE 
> Frameworks to build. David Faure has suggested to use fix like this one until 
> at least Frameworks 5.15 have been released.
> 
> I don't have commit access, so someone needs to commit this for me.
> 
> 
> Diffs
> -
> 
>   applets/icon/plugin/icon_p.cpp 97af67a 
> 
> Diff: https://git.reviewboard.kde.org/r/125187/diff/
> 
> 
> Testing
> ---
> 
> It builds.
> 
> 
> Thanks,
> 
> Armin K.
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 125234: [wayland] Add key repeat information

[Kai Uwe Broulik]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125234/#review85422
---

Ship it!



Modules/base/info_wayland.cpp (line 100)


QStringList{i18n("Keyboard")}


- Kai Uwe Broulik


On Sept. 15, 2015, 8:25 vorm., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125234/
> ---
> 
> (Updated Sept. 15, 2015, 8:25 vorm.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: kinfocenter
> 
> 
> Description
> ---
> 
> I needed a way to test whether KWin properly exports key repeat ;-)
> 
> 
> Diffs
> -
> 
>   Modules/base/info_wayland.cpp e27c18e358a6697ec3c919246ad56551ab933433 
> 
> Diff: https://git.reviewboard.kde.org/r/125234/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> Kinfocenter with key repeat information
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/09/15/754e6b03-71ff-452f-89f3-b0e0237331b0__kwin_screenshot_bZ7878.png
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 125198: by default do not restore the previous session on next login

[Harald Sitter]

> On Sept. 14, 2015, 6:05 a.m., Martin Gräßlin wrote:
> > +1 - as a note: in openSUSE users were quite angry that we had broken 
> > session management, they won't be glad about the choice. My personal 
> > opinion is (as many probably known) that I would drop all session 
> > management support as I consider it as a relict from pre-suspend times.
> 
> Marco Martin wrote:
> I still tend to prefer it to suspend, starts things kindof where i was 
> but slightly more clean slate than suspend (maybe is also due that i still do 
> find suspend unreliable and horribly slow with 8 or more GB of ram).
> It's fine to disable it by default, but the thing I'm afraid is that it 
> may break again without being noticed, and i definitely want to keep it and 
> keep it working for the time being.

Suspend to harddisk is sometimes weirdly broken. Suspend in general has some 
hardware detection problems (see steamos suspend disabled because usb devices 
do not get detected when coming out of suspend). At the same time as I 
mentioned yesterday on IRC session restore often requires explicit support to 
be implemented on an application level which also renders it part-defunct 
depending on the applications one uses as the application will often just come 
up with the default UI state which conceptually is not "restoring" but 
"reopening". All in all both options are meh at times.

So, I'd argue that suspend should be the go-to choice for the "restore" feature 
and we should demote session management as a "reopening"-only feature. 
Specifically that means changing the name and advertising it in that fashion 
which is line with what Kai suggested above as reopening is a much more 
immediate choice you want to make on logout actions. This also means that we'd 
consider it correct behavior if an application comes up in its default UI 
state. If an application chooses to implement restore that is cool as well but 
not required from a UX POV.


- Harald


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125198/#review85343
---


On Sept. 12, 2015, 3:37 p.m., Harald Sitter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125198/
> ---
> 
> (Updated Sept. 12, 2015, 3:37 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> As requested by the VDG.
> Rationale being that starting with an empty session all the time is
> substantially less aggressive than potentially starting a gazillion
> applications slowing down startup and greeting the user with a
> cluttered desktop.
> 
> 
> Diffs
> -
> 
>   ksmserver/main.cpp 4808a80081c3f4322c0d1b3223fc65bcbfeb26c1 
>   ksmserver/shutdown.cpp 636ae66fcce1d5c39fd697925b9094abc44e4808 
> 
> Diff: https://git.reviewboard.kde.org/r/125198/diff/
> 
> 
> Testing
> ---
> 
> installed. wiped ksmserverrc. multiple logins always result in an empty 
> session.
> 
> 
> Thanks,
> 
> Harald Sitter
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request 125235: Make sure the cancel and shutdown/logout button have the same size

[Aleix Pol Gonzalez]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125235/
---

Review request for Plasma.


Repository: plasma-workspace


Description
---

The RowLayout squeezed them, now we ensure we have a big enough button for both 
actions.


Diffs
-

  lookandfeel/contents/components/LogoutScreen.qml 02296d5 

Diff: https://git.reviewboard.kde.org/r/125235/diff/


Testing
---

Screenshot: http://i.imgur.com/G9rTHKB.png


Thanks,

Aleix Pol Gonzalez

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 125198: by default do not restore the previous session on next login

[Marco Martin]

> On Sept. 14, 2015, 6:05 a.m., Martin Gräßlin wrote:
> > +1 - as a note: in openSUSE users were quite angry that we had broken 
> > session management, they won't be glad about the choice. My personal 
> > opinion is (as many probably known) that I would drop all session 
> > management support as I consider it as a relict from pre-suspend times.
> 
> Marco Martin wrote:
> I still tend to prefer it to suspend, starts things kindof where i was 
> but slightly more clean slate than suspend (maybe is also due that i still do 
> find suspend unreliable and horribly slow with 8 or more GB of ram).
> It's fine to disable it by default, but the thing I'm afraid is that it 
> may break again without being noticed, and i definitely want to keep it and 
> keep it working for the time being.
> 
> Harald Sitter wrote:
> Suspend to harddisk is sometimes weirdly broken. Suspend in general has 
> some hardware detection problems (see steamos suspend disabled because usb 
> devices do not get detected when coming out of suspend). At the same time as 
> I mentioned yesterday on IRC session restore often requires explicit support 
> to be implemented on an application level which also renders it part-defunct 
> depending on the applications one uses as the application will often just 
> come up with the default UI state which conceptually is not "restoring" but 
> "reopening". All in all both options are meh at times.
> 
> So, I'd argue that suspend should be the go-to choice for the "restore" 
> feature and we should demote session management as a "reopening"-only 
> feature. Specifically that means changing the name and advertising it in that 
> fashion which is line with what Kai suggested above as reopening is a much 
> more immediate choice you want to make on logout actions. This also means 
> that we'd consider it correct behavior if an application comes up in its 
> default UI state. If an application chooses to implement restore that is cool 
> as well but not required from a UX POV.

may make sense, i don't like much the layout, would be probably be better on 
the same line of the button at the right of the screen (but then i fear seeing 
that line of text in german :/)


- Marco


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125198/#review85343
---


On Sept. 12, 2015, 3:37 p.m., Harald Sitter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125198/
> ---
> 
> (Updated Sept. 12, 2015, 3:37 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> As requested by the VDG.
> Rationale being that starting with an empty session all the time is
> substantially less aggressive than potentially starting a gazillion
> applications slowing down startup and greeting the user with a
> cluttered desktop.
> 
> 
> Diffs
> -
> 
>   ksmserver/main.cpp 4808a80081c3f4322c0d1b3223fc65bcbfeb26c1 
>   ksmserver/shutdown.cpp 636ae66fcce1d5c39fd697925b9094abc44e4808 
> 
> Diff: https://git.reviewboard.kde.org/r/125198/diff/
> 
> 
> Testing
> ---
> 
> installed. wiped ksmserverrc. multiple logins always result in an empty 
> session.
> 
> 
> Thanks,
> 
> Harald Sitter
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 125226: move EventForge from the desktop containment

[Marco Martin]

On Sept. 15, 2015, 12:06 a.m., Marco Martin wrote:
> > This class feels like it's just working round Qt bugs?
> > 
> > Other than that if this is long-term useful, we should do sendPress(flags 
> > buttons, flags modifiers, x, y) not just whatever AppletAppearance happened 
> > to need (or make it part of makeGrab() if that's all it's for )
> 
> Marco Martin wrote:
> It can be said it work around Qt bugs, so yeah, not too happy it's needed.
> maybe to commit to it slightly less it could be put into the 
> plasma-workspace imports (as to say it can be used only in containments)
> But works around the very way how events are managed in Qt. once a child 
> accepted a press (and maybe some moves) it can't really be interrupted as two 
> items can't accept the same event. So this fakes it by sending fake events to 
> cancel the management cycle initiated by the child on mouyse press. don't 
> think there is really a way about it as is how Qt event management work (and 
> not only in qtquick)

an alternative API may be
PressAndHoldManager {
dragArea: dragAreaItem
MouseArea {
id: dragAreaItem
MouseArea {
id: itemToDrag
}
}
}

not sure it it would really work


- Marco


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125226/#review85410
---


On Sept. 14, 2015, 5:17 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125226/
> ---
> 
> (Updated Sept. 14, 2015, 5:17 p.m.)
> 
> 
> Review request for KDE Frameworks, Plasma and Eike Hein.
> 
> 
> Repository: kdeclarative
> 
> 
> Description
> ---
> 
> EventForge can cancel the half-managed events of child items
> in order to implement the move of them with press and hold,
> not having the parent and the children battling for the same
> press-move-release event sequence.
> 
> API-wise I think it's fine, apart perhaps the EventForge class name
> (perhaps MouseEventGrabber is less technically correct, but still more clear?)
> 
> 
> Diffs
> -
> 
>   src/qmlcontrols/kquickcontrolsaddons/CMakeLists.txt 5b711e1 
>   src/qmlcontrols/kquickcontrolsaddons/eventforge.h PRE-CREATION 
>   src/qmlcontrols/kquickcontrolsaddons/eventforge.cpp PRE-CREATION 
>   src/qmlcontrols/kquickcontrolsaddons/kquickcontrolsaddonsplugin.cpp a33e03f 
> 
> Diff: https://git.reviewboard.kde.org/r/125226/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Jenkins-kde-ci: plasma-workspace Plasma-5.4 stable-kf5-qt5 » Linux,gcc - Build # 23 - Fixed!

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/plasma-workspace%20Plasma-5.4%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/23/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Tue, 15 Sep 2015 09:53:14 +
Build duration: 7 min 17 sec

CHANGE SET
Revision 93bf81eea152e2b8261ac4a854207af448ed7c43 by aleixpol: (Make sure the 
cancel and shutdown/logout button have the same size)
  change: edit lookandfeel/contents/components/LogoutScreen.qml


JUNIT RESULTS

Name: (root) Failed: 0 test(s), Passed: 10 test(s), Skipped: 0 test(s), Total: 
10 test(s)

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 14/14 (100%)FILES 61/71 (86%)CLASSES 61/71 (86%)LINE 2473/4040 
(61%)CONDITIONAL 1467/2288 (64%)

By packages
  
drkonqi.parser
FILES 6/10 (60%)CLASSES 6/10 (60%)LINE 302/422 (72%)CONDITIONAL 
436/495 (88%)
drkonqi.tests.backtraceparsertest
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 77/77 (100%)CONDITIONAL 
33/50 (66%)
kioslave.desktop
FILES 2/3 (67%)CLASSES 2/3 (67%)LINE 111/149 (74%)CONDITIONAL 
40/70 (57%)
kioslave.desktop.tests
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 66/66 (100%)CONDITIONAL 
26/50 (52%)
klipper
FILES 12/13 (92%)CLASSES 12/13 (92%)LINE 258/379 
(68%)CONDITIONAL 109/146 (75%)
klipper.autotests
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 614/677 (91%)CONDITIONAL 
377/742 (51%)
ksmserver.screenlocker
FILES 8/11 (73%)CLASSES 8/11 (73%)LINE 460/977 (47%)CONDITIONAL 
139/219 (63%)
ksmserver.screenlocker.autotests
FILES 5/5 (100%)CLASSES 5/5 (100%)LINE 165/169 (98%)CONDITIONAL 
65/124 (52%)
ksmserver.screenlocker.greeter
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 99/144 (69%)CONDITIONAL 
36/60 (60%)
ksmserver.screenlocker.greeter.autotests
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 45/45 (100%)CONDITIONAL 
34/68 (50%)
libkworkspace
FILES 2/3 (67%)CLASSES 2/3 (67%)LINE 28/610 (5%)CONDITIONAL 
23/39 (59%)
runners.bookmarks
FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 87/160 (54%)CONDITIONAL 
34/56 (61%)
runners.bookmarks.browsers
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 96/100 (96%)CONDITIONAL 
84/107 (79%)
runners.bookmarks.tests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 65/65 (100%)CONDITIONAL 
31/62 (50%)___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Powerdevil] [Bug 350676] Need to press key twice to decrease brightness

[Igor Poboiko]

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

--- Comment #15 from Igor Poboiko  ---
(In reply to Weng Xuetian from comment #12)
> Disable vsync helps me to workaround the issue, you may try that to see if
> it works for you..
No, unfortunately it didn't.

(In reply to Weng Xuetian from comment #14)
> FYI, https://git.reviewboard.kde.org/r/125182/
What's the status of that patch? 
That check was there from very beginning, as far as I can see from git log. 
But I guess it shouldn't be there. Seems like the logic there is following: if
cache is somehow broken, we should update a cache, but ignore a keypress. I
believe it's not a correct behavior. We should just update a cache and keep
going!
And removing that check would have also solved that issue as well.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 125226: move EventForge from the desktop containment

[Marco Martin]

On Sept. 15, 2015, 12:06 a.m., Marco Martin wrote:
> > This class feels like it's just working round Qt bugs?
> > 
> > Other than that if this is long-term useful, we should do sendPress(flags 
> > buttons, flags modifiers, x, y) not just whatever AppletAppearance happened 
> > to need (or make it part of makeGrab() if that's all it's for )

It can be said it work around Qt bugs, so yeah, not too happy it's needed.
maybe to commit to it slightly less it could be put into the plasma-workspace 
imports (as to say it can be used only in containments)
But works around the very way how events are managed in Qt. once a child 
accepted a press (and maybe some moves) it can't really be interrupted as two 
items can't accept the same event. So this fakes it by sending fake events to 
cancel the management cycle initiated by the child on mouyse press. don't think 
there is really a way about it as is how Qt event management work (and not only 
in qtquick)


- Marco


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125226/#review85410
---


On Sept. 14, 2015, 5:17 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125226/
> ---
> 
> (Updated Sept. 14, 2015, 5:17 p.m.)
> 
> 
> Review request for KDE Frameworks, Plasma and Eike Hein.
> 
> 
> Repository: kdeclarative
> 
> 
> Description
> ---
> 
> EventForge can cancel the half-managed events of child items
> in order to implement the move of them with press and hold,
> not having the parent and the children battling for the same
> press-move-release event sequence.
> 
> API-wise I think it's fine, apart perhaps the EventForge class name
> (perhaps MouseEventGrabber is less technically correct, but still more clear?)
> 
> 
> Diffs
> -
> 
>   src/qmlcontrols/kquickcontrolsaddons/CMakeLists.txt 5b711e1 
>   src/qmlcontrols/kquickcontrolsaddons/eventforge.h PRE-CREATION 
>   src/qmlcontrols/kquickcontrolsaddons/eventforge.cpp PRE-CREATION 
>   src/qmlcontrols/kquickcontrolsaddons/kquickcontrolsaddonsplugin.cpp a33e03f 
> 
> Diff: https://git.reviewboard.kde.org/r/125226/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Jenkins-kde-ci: plasma-workspace Plasma-5.4 stable-kf5-qt5 » Linux,gcc - Build # 23 - Fixed!

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/plasma-workspace%20Plasma-5.4%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/23/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Tue, 15 Sep 2015 09:53:14 +
Build duration: 7 min 17 sec

CHANGE SET
Revision 93bf81eea152e2b8261ac4a854207af448ed7c43 by aleixpol: (Make sure the 
cancel and shutdown/logout button have the same size)
  change: edit lookandfeel/contents/components/LogoutScreen.qml


JUNIT RESULTS

Name: (root) Failed: 0 test(s), Passed: 10 test(s), Skipped: 0 test(s), Total: 
10 test(s)

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 14/14 (100%)FILES 61/71 (86%)CLASSES 61/71 (86%)LINE 2473/4040 
(61%)CONDITIONAL 1467/2288 (64%)

By packages
  
drkonqi.parser
FILES 6/10 (60%)CLASSES 6/10 (60%)LINE 302/422 (72%)CONDITIONAL 
436/495 (88%)
drkonqi.tests.backtraceparsertest
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 77/77 (100%)CONDITIONAL 
33/50 (66%)
kioslave.desktop
FILES 2/3 (67%)CLASSES 2/3 (67%)LINE 111/149 (74%)CONDITIONAL 
40/70 (57%)
kioslave.desktop.tests
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 66/66 (100%)CONDITIONAL 
26/50 (52%)
klipper
FILES 12/13 (92%)CLASSES 12/13 (92%)LINE 258/379 
(68%)CONDITIONAL 109/146 (75%)
klipper.autotests
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 614/677 (91%)CONDITIONAL 
377/742 (51%)
ksmserver.screenlocker
FILES 8/11 (73%)CLASSES 8/11 (73%)LINE 460/977 (47%)CONDITIONAL 
139/219 (63%)
ksmserver.screenlocker.autotests
FILES 5/5 (100%)CLASSES 5/5 (100%)LINE 165/169 (98%)CONDITIONAL 
65/124 (52%)
ksmserver.screenlocker.greeter
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 99/144 (69%)CONDITIONAL 
36/60 (60%)
ksmserver.screenlocker.greeter.autotests
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 45/45 (100%)CONDITIONAL 
34/68 (50%)
libkworkspace
FILES 2/3 (67%)CLASSES 2/3 (67%)LINE 28/610 (5%)CONDITIONAL 
23/39 (59%)
runners.bookmarks
FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 87/160 (54%)CONDITIONAL 
34/56 (61%)
runners.bookmarks.browsers
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 96/100 (96%)CONDITIONAL 
84/107 (79%)
runners.bookmarks.tests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 65/65 (100%)CONDITIONAL 
31/62 (50%)___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 125187: Stop requiring Frameworks 5.15

[Martin Gräßlin]

> On Sept. 14, 2015, 10:44 a.m., Martin Gräßlin wrote:
> > -2, a change for a month in the devel branch doesn't make much sense.
> 
> David Faure wrote:
> As you want. You're raising the bar for new contributors, who can't work 
> on your code using the latest KDE Frameworks release.
> 
> You and me might compile everything, but you'll get more contributors if 
> you let people work on workspace and apps using a released frameworks (for 
> which there are distro packages) than if you require them to compile 
> frameworks first. Just like we don't require Qt from git, we shouldn't 
> require KF5 from git, I thought this was the general agreement.
> 
> If you're worried about the ifdef, just use the two liner version of the 
> code forever, I was always a bit dubious about adding a method just for that 
> anyway.
> 
> Martin Gräßlin wrote:
> It's really not that uncommon to depend on latest frameworks in 
> workspace. It's common that I add things in KWindowSystem to make use of it 
> in KWin directly. Or lately I used lots of new functionalty from KGlobalAccel 
> directly.
> 
> Yes it raises the entry level, but it's also rather unlikely that we are 
> able to a policy forbidding depending on frameworks master without CI checks.
> 
> Sebastian Kügler wrote:
> Besides, these occasional devs can use the stable branch en then forward 
> port?
> 
> Marco Martin wrote:
> -2 from here as well for the same reasons
> 
> Ben Cooksley wrote:
> Please note that the CI system is shifting towards only allowing usage of 
> released products. We'll also be imposing a dependency prohibition between 
> Applications and Plasma so there will no longer be any ability to have 
> dependencies between the two.
> 
> Aleix Pol Gonzalez wrote:
> @Ben: Really? Why? Where was this discussed?
> 
> Martin Gräßlin wrote:
> @Ben: where should libraries like kwayland and kdecoration go then? They 
> do not fit requirements of frameworks but might be useable to applications 
> (kwayland is a must have library for any wayland integration).
> 
> Ben Cooksley wrote:
> That has yet to be resolved. Likely another layer which will be released 
> as needed by Applications / Plasma which sits in between Frameworks and them 
> will be added I suspect. No binary compatibility commitments, same licensing 
> rules as Applications / Plasma, just a logically separate product so it 
> doesn't cause dependency problems. I don't expect too many libraries or 
> runtime components to end up there (Dr Konqi might perhaps?).

Honestly: I don't see the point in that except of making everything more 
complicated (yet another product which has a dedicated release cycle). If 
applications want to depend on workspace libraries: that's fine. They know what 
it means. We shouldn't prevent "stupid things" in the CI system.


- Martin


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125187/#review85353
---


On Sept. 12, 2015, 11:38 a.m., Armin K. wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125187/
> ---
> 
> (Updated Sept. 12, 2015, 11:38 a.m.)
> 
> 
> Review request for Plasma and David Faure.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> KDesktopFile.readMimeTypes(); hasn't made it into Frameworks 5.14, causing 
> plasma-workspace git master to depend on yet unreleased version of KDE 
> Frameworks to build. David Faure has suggested to use fix like this one until 
> at least Frameworks 5.15 have been released.
> 
> I don't have commit access, so someone needs to commit this for me.
> 
> 
> Diffs
> -
> 
>   applets/icon/plugin/icon_p.cpp 97af67a 
> 
> Diff: https://git.reviewboard.kde.org/r/125187/diff/
> 
> 
> Testing
> ---
> 
> It builds.
> 
> 
> Thanks,
> 
> Armin K.
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 125226: move EventForge from the desktop containment

[David Edmundson]

> On Sept. 15, 2015, 12:06 a.m., David Edmundson wrote:
> > src/qmlcontrols/kquickcontrolsaddons/eventforge.cpp, line 51
> > 
> >
> > why do people need to do this?
> 
> Eike Hein wrote:
> It basically triggers the onCanceled handler in MouseArea and 
> MouseEventListener, and is used to abort mouse handling in applet items when 
> you enable applet moving via press and hold in the containment. Flickable 
> does similar things internally for flicking the viewport, but Qt only has 
> private API for it (which isn't easily made public); this is the closest 
> approximation using public API.

Don't tell me, tell the .cpp file :)


- David


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125226/#review85410
---


On Sept. 15, 2015, 5:32 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125226/
> ---
> 
> (Updated Sept. 15, 2015, 5:32 p.m.)
> 
> 
> Review request for KDE Frameworks, Plasma and Eike Hein.
> 
> 
> Repository: kdeclarative
> 
> 
> Description
> ---
> 
> EventForge can cancel the half-managed events of child items
> in order to implement the move of them with press and hold,
> not having the parent and the children battling for the same
> press-move-release event sequence.
> 
> API-wise I think it's fine, apart perhaps the EventForge class name
> (perhaps MouseEventGrabber is less technically correct, but still more clear?)
> 
> 
> Diffs
> -
> 
>   src/qmlcontrols/kquickcontrolsaddons/mouseeventlistener.h a62efb7 
>   src/qmlcontrols/kquickcontrolsaddons/mouseeventlistener.cpp d3321a3 
> 
> Diff: https://git.reviewboard.kde.org/r/125226/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 125248: Display name of process which blocks umount / eject

[Igor Poboiko]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125248/
---

(Updated Сен. 15, 2015, 9:41 п.п.)


Review request for Plasma and Solid.


Repository: plasma-workspace


Description
---

An attempt to implement feature from [bug 
96107](https://bugs.kde.org/show_bug.cgi?id=96107) (see summary).

On umount/eject error it runs "lsof" executable, gets PIDs of blocking 
processes and obtains names of processes via KSysGuard::Process machinery. 
Finally it appends obtained information to error message which is shown in 
tooltip of Device Notifier applet.


Diffs (updated)
-

  dataengines/devicenotifications/CMakeLists.txt 3f7fd83 
  dataengines/devicenotifications/ksolidnotify.cpp 35d49d6 

Diff: https://git.reviewboard.kde.org/r/125248/diff/


Testing
---

Tested unmount on busy device with several processes blocking it. Did not test 
eject, since I have no optical disc drive :(


File Attachments


Applet with error message
  
https://git.reviewboard.kde.org/media/uploaded/files/2015/09/15/3b1b64fc-abff-4633-9dca-621388edf086__snapshot11.png


Thanks,

Igor Poboiko

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 125248: Display name of process which blocks umount / eject

[Martin Klapetek]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125248/#review85458
---


Yes!! Thank you. Couple nitpickings below.


dataengines/devicenotifications/ksolidnotify.cpp (line 136)


const QString _s



dataengines/devicenotifications/ksolidnotify.cpp (line 138)


( pid ) --> (pid)



dataengines/devicenotifications/ksolidnotify.cpp (line 139)


KSysGuard::Process* proc --> KSysGuard::Process *proc



dataengines/devicenotifications/ksolidnotify.cpp (lines 146 - 149)


We put braces around if-else -->

if () {

} else {

}



dataengines/devicenotifications/ksolidnotify.cpp (lines 178 - 201)


It would appear that this is a duplicated function, please make it a 
function and then just call that function in both places


Y

- Martin Klapetek


On Sept. 15, 2015, 10:50 p.m., Igor Poboiko wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125248/
> ---
> 
> (Updated Sept. 15, 2015, 10:50 p.m.)
> 
> 
> Review request for Plasma and Solid.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> An attempt to implement feature from [bug 
> 96107](https://bugs.kde.org/show_bug.cgi?id=96107) (see summary).
> 
> On umount/eject error it runs "lsof" executable, gets PIDs of blocking 
> processes and obtains names of processes via KSysGuard::Process machinery. 
> Finally it appends obtained information to error message which is shown in 
> tooltip of Device Notifier applet.
> 
> 
> Diffs
> -
> 
>   dataengines/devicenotifications/CMakeLists.txt 3f7fd83 
>   dataengines/devicenotifications/ksolidnotify.cpp 35d49d6 
> 
> Diff: https://git.reviewboard.kde.org/r/125248/diff/
> 
> 
> Testing
> ---
> 
> Tested unmount on busy device with several processes blocking it. Did not 
> test eject, since I have no optical disc drive :(
> 
> 
> File Attachments
> 
> 
> Applet with error message
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/09/15/3b1b64fc-abff-4633-9dca-621388edf086__snapshot11.png
> 
> 
> Thanks,
> 
> Igor Poboiko
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 125223: Add support for transient to ShellSurface(Interface)

[Sebastian Kügler]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125223/#review85459
---

Ship it!


Ship It!

- Sebastian Kügler


On Sept. 14, 2015, 2:33 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125223/
> ---
> 
> (Updated Sept. 14, 2015, 2:33 p.m.)
> 
> 
> Review request for Plasma and Sebastian Kügler.
> 
> 
> Repository: kwayland
> 
> 
> Description
> ---
> 
> On client side a setTransient method is added which wraps the semantic
> of wl_shell_surface_set_transient.
> 
> On server side both set_transient and set_popup are implemented, though
> for popup only the transient part is implemented. In particular the grab
> is not yet handled and also no popup done is provided.
> 
> For the transient on server side the flags are ignored. Main reason is
> that Qt does not use the flag, so testing whether it works is tricky
> (needs a test application).
> 
> 
> Diffs
> -
> 
>   autotests/client/test_wayland_shell.cpp 
> 89101f4443a1b412a922c99bfe59d06ef1401468 
>   src/client/shell.h 0777c51da0c2c2568e664af5fe1db51fa5c028bb 
>   src/client/shell.cpp 94eb4de497d3cfd813fb01aa2dc53591ba749f9c 
>   src/server/shell_interface.h dfbc1f077696bdd73039731fd256de656caf9f38 
>   src/server/shell_interface.cpp a2d241f5d9cdb03a0526c70f2af046c7ec4dc19f 
> 
> Diff: https://git.reviewboard.kde.org/r/125223/diff/
> 
> 
> Testing
> ---
> 
> See extended autotest. Also KWin extended to make use of it: All kind of 
> menus (QMenu, context menu, dropdown) are positioned correctly now.
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 125129: Update baloo's D-Bus interface name in KCM

[Vishesh Handa]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125129/#review85462
---


Maybe we could just add this to our `IndexerConfig` class so that users of our 
API don't need to know about dbus interfaces? Specially since I'm not too keen 
on maintaining API comatibility in the dbus interface.

- Vishesh Handa


On Sept. 10, 2015, 5:56 a.m., Pinak Ahuja wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125129/
> ---
> 
> (Updated Sept. 10, 2015, 5:56 a.m.)
> 
> 
> Review request for Plasma and Vishesh Handa.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> Also generate interface from XML
> 
> 
> Diffs
> -
> 
>   kcms/baloo/CMakeLists.txt 7415289 
>   kcms/baloo/kcm.cpp d85f615 
> 
> Diff: https://git.reviewboard.kde.org/r/125129/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Pinak Ahuja
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 125117: Moved check for all mount points excluded out of widget class

[Vishesh Handa]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125117/#review85465
---



kcms/baloo/kcm.cpp (line 168)


I'm really not too sure about this. So the display name is taken and that 
is compared with the mountPoint?

The display name isn't always equal to the mount path or is it?

http://doc.qt.io/qt-5/qstorageinfo.html#displayName


- Vishesh Handa


On Sept. 9, 2015, 6:53 p.m., Ovidiu-Florin BOGDAN wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125117/
> ---
> 
> (Updated Sept. 9, 2015, 6:53 p.m.)
> 
> 
> Review request for Baloo, Plasma and Vishesh Handa.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> And simplified the way it searches for the mount points.
> 
> 
> Diffs
> -
> 
>   kcms/baloo/folderselectionwidget.h 6430b60 
>   kcms/baloo/folderselectionwidget.cpp 3ad1764 
>   kcms/baloo/kcm.h 6878e89 
>   kcms/baloo/kcm.cpp d85f615 
> 
> Diff: https://git.reviewboard.kde.org/r/125117/diff/
> 
> 
> Testing
> ---
> 
> Compiled and used.
> 
> 
> Thanks,
> 
> Ovidiu-Florin BOGDAN
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 125226: move EventForge from the desktop containment

[David Edmundson]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125226/#review85466
---



src/qmlcontrols/kquickcontrolsaddons/mouseeventlistener.cpp (line 257)


This adds the same item multiple times.

If you have an item with a child: the first itteration will add it and the 
child, then we recurse and add the child again.

I think you can kill the

itemList.append(parentItem->childItems()) 

?


- David Edmundson


On Sept. 15, 2015, 5:32 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125226/
> ---
> 
> (Updated Sept. 15, 2015, 5:32 p.m.)
> 
> 
> Review request for KDE Frameworks, Plasma and Eike Hein.
> 
> 
> Repository: kdeclarative
> 
> 
> Description
> ---
> 
> EventForge can cancel the half-managed events of child items
> in order to implement the move of them with press and hold,
> not having the parent and the children battling for the same
> press-move-release event sequence.
> 
> API-wise I think it's fine, apart perhaps the EventForge class name
> (perhaps MouseEventGrabber is less technically correct, but still more clear?)
> 
> 
> Diffs
> -
> 
>   src/qmlcontrols/kquickcontrolsaddons/mouseeventlistener.h a62efb7 
>   src/qmlcontrols/kquickcontrolsaddons/mouseeventlistener.cpp d3321a3 
> 
> Diff: https://git.reviewboard.kde.org/r/125226/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 125226: move EventForge from the desktop containment

[Eike Hein]

> On Sept. 15, 2015, 12:06 a.m., David Edmundson wrote:
> > src/qmlcontrols/kquickcontrolsaddons/eventforge.cpp, line 51
> > 
> >
> > why do people need to do this?

It basically triggers the onCanceled handler in MouseArea and 
MouseEventListener, and is used to abort mouse handling in applet items when 
you enable applet moving via press and hold in the containment. Flickable does 
similar things internally for flicking the viewport, but Qt only has private 
API for it (which isn't easily made public); this is the closest approximation 
using public API.


> On Sept. 15, 2015, 12:06 a.m., David Edmundson wrote:
> > src/qmlcontrols/kquickcontrolsaddons/eventforge.cpp, line 40
> > 
> >
> > we're getting win and not using it. Is that deliberate?

I probably meant to use QQuickWindow::sendEvent


- Eike


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125226/#review85410
---


On Sept. 15, 2015, 5:32 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125226/
> ---
> 
> (Updated Sept. 15, 2015, 5:32 p.m.)
> 
> 
> Review request for KDE Frameworks, Plasma and Eike Hein.
> 
> 
> Repository: kdeclarative
> 
> 
> Description
> ---
> 
> EventForge can cancel the half-managed events of child items
> in order to implement the move of them with press and hold,
> not having the parent and the children battling for the same
> press-move-release event sequence.
> 
> API-wise I think it's fine, apart perhaps the EventForge class name
> (perhaps MouseEventGrabber is less technically correct, but still more clear?)
> 
> 
> Diffs
> -
> 
>   src/qmlcontrols/kquickcontrolsaddons/mouseeventlistener.h a62efb7 
>   src/qmlcontrols/kquickcontrolsaddons/mouseeventlistener.cpp d3321a3 
> 
> Diff: https://git.reviewboard.kde.org/r/125226/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request 125248: Display name of process which blocks umount / eject

[Igor Poboiko]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125248/
---

Review request for Plasma and Solid.


Repository: plasma-workspace


Description
---

An attempt to implement feature from [bug 
96107](https://bugs.kde.org/show_bug.cgi?id=96107) (see summary).

On umount/eject error it runs "lsof" executable, gets PIDs of blocking 
processes and obtains names of processes via KSysGuard::Process machinery. 
Finally it appends obtained information to error message which is shown in 
tooltip of Device Notifier applet.


Diffs
-

  dataengines/devicenotifications/CMakeLists.txt 3f7fd83 
  dataengines/devicenotifications/ksolidnotify.cpp 35d49d6 

Diff: https://git.reviewboard.kde.org/r/125248/diff/


Testing
---

Tested unmount on busy device with several processes blocking it. Did not test 
eject, since I have no optical disc drive :(


File Attachments


Applet with error message
  
https://git.reviewboard.kde.org/media/uploaded/files/2015/09/15/3b1b64fc-abff-4633-9dca-621388edf086__snapshot11.png


Thanks,

Igor Poboiko

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 125240: Use lineedit svg margins in sizeHint calculation

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125240/#review85446
---

Ship it!


Ship It!

- Marco Martin


On Sept. 15, 2015, 1:50 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125240/
> ---
> 
> (Updated Sept. 15, 2015, 1:50 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> QQC button heights are max(backgroundHeight, label + margins).
> QQC lineedits heights are set from the background, ignoring the margins for 
> size. Only using it for the offset of the TextInput within the frame.
> 
> We need to take the margins into consideration when deciding how high
> the textbox should be otherwise we're effectively just ignoring the SVG 
> theme. 
> 
> This means button and textbox on the login screen are now the same
> height \o/. 
> 
> I had always assumed till now it was deliberate / the SVG hints were wrong.
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/plasmastyle/TextFieldStyle.qml 
> 8daaa0b8355947cba920106f9d1cae3f3adb0200 
>   tests/components/button.qml 55d7dfbe9424736db56a1ebce5771a4592e20a98 
> 
> Diff: https://git.reviewboard.kde.org/r/125240/diff/
> 
> 
> Testing
> ---
> 
> Looked at some applets and stuff that used textboxes... all looked 2px 
> higher. 
> 
> Shouldn't have any visible breakages as all existing code should have
> handled different themes with different heights anyway.
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Powerdevil] [Bug 350676] Need to press key twice to decrease brightness

[Weng Xuetian]

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

--- Comment #16 from Weng Xuetian  ---
(In reply to Igor Poboiko from comment #15)
> (In reply to Weng Xuetian from comment #14)
> > FYI, https://git.reviewboard.kde.org/r/125182/
> What's the status of that patch? 
> That check was there from very beginning, as far as I can see from git log. 
> But I guess it shouldn't be there. Seems like the logic there is following:
> if cache is somehow broken, we should update a cache, but ignore a keypress.
> I believe it's not a correct behavior. We should just update a cache and
> keep going!
> And removing that check would have also solved that issue as well.
You may want to comment on the review instead of discuss at the bug report
here.
The reason that I don't want to update the cachedBrightness is, other usage of
it shows that it always keeps real hardware brightness value with in it is used
to whether to send brightness changed signal or not. From existing code, it
seems that the code tries to avoid querying hardware value frequently and send
a lot of brightness changed during animation.

The reason that the animation value is fake is because something like this may
happen: you set 35 to hardware, but hardware probably gives you 30 in the end.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request 125240: Use lineedit svg margins in sizeHint calculation

[David Edmundson]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125240/
---

Review request for Plasma.


Repository: plasma-framework


Description
---

QQC button heights are max(backgroundHeight, label + margins).
QQC lineedits heights are set from the background, ignoring the margins for 
size. Only using it for the offset of the TextInput within the frame.

We need to take the margins into consideration when deciding how high
the textbox should be otherwise we're effectively just ignoring the SVG theme. 

This means button and textbox on the login screen are now the same
height \o/. 

I had always assumed till now it was deliberate / the SVG hints were wrong.


Diffs
-

  src/declarativeimports/plasmastyle/TextFieldStyle.qml 
8daaa0b8355947cba920106f9d1cae3f3adb0200 
  tests/components/button.qml 55d7dfbe9424736db56a1ebce5771a4592e20a98 

Diff: https://git.reviewboard.kde.org/r/125240/diff/


Testing
---

Looked at some applets and stuff that used textboxes... all looked 2px higher. 

Shouldn't have any visible breakages as all existing code should have
handled different themes with different heights anyway.


Thanks,

David Edmundson

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel