date:20160413

This revision was automatically updated to reflect the committed changes.
Closed by commit rPLASMAINTEGRATION1feb62b2521a: Add PROJECT_VERSION to 
CMakeLists.txt (authored by graesslin).

REPOSITORY
  rPLASMAINTEGRATION Integration for Qt applications in Plasma

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D1396?vs=3307=3327

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

AFFECTED FILES
  CMakeLists.txt

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, Plasma, bshah
Cc: plasma-devel, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 127631: [ksmserver] We must be sure that kwin process is ended



> On April 11, 2016, 7:45 a.m., Martin Gräßlin wrote:
> > > otherwise kwindowsystem::self() is nullptr
> > 
> > how can KWindowSystem::self() be null? And why should that have anything to 
> > do with KWin? KWindowSystem does not depend on a window manager running.
> 
> Thomas Lübking wrote:
> The entire thing sounds as if the problem would be that the session 
> restorage in kwin overrides the placement for restored windows (with the 
> restored position)
> 
> That's however not a bug (at least it's intended) and I've no idea why 
> that's relevant to the weird geometry handling of SNI items (which looks 
> *fr* too complex - the position of remapped windows is usually maintained 
> by QWidget ...)
> 
> Anthony Fieroni wrote:
> I saw the code, it looks like KWindowSystem not depend on Kwin, but Kwin 
> *must* be started *before* use of kwindowsystem. Thomas may right, because 
> setGeometry even not work on sessions restored app.
> When session was finish if start apps with kmail --session session-id 
> everything wors fine.
> 
> Anthony Fieroni wrote:
> Now, after Thomas comment, i even think only widget->show() must works 
> because widget has internal frameGeometry and position.
> 
> Martin Gräßlin wrote:
> > but Kwin must be started before use of kwindowsystem
> 
> no, really there is no reason for that. KWindowSystem doesn't depend on a 
> window manager running.
> 
> Anthony Fieroni wrote:
> Then, correct KWin to kwindowsystem to start working. If there is no bug 
> this will works on all cases -> https://git.reviewboard.kde.org/r/127216/ but 
> it's not.
> 
> Martin Gräßlin wrote:
> I don't know why you have problems, but it's impossible that 
> KWindowSystem::self() returns a nullptr. You can check the code to verify. 
> Something is really broken on your side, but I don't know what. Maybe missing 
> plugins installed?
> 
> Thomas Lübking wrote:
> it's not a hard dependecy on the instace, the sni geometry handling is 
> just plain broken.
> the workaround operates on configure events on the mapped window which 
> will go nowhere if there's no running wm.
> 
> the client needs to handle the no-wm case, ie. configure the window 
> correctly, but to repeat myself: such requirement implies that either sni or 
> qwidget/qwindow is completely fucked up.
> 
> qwindow/qwidget::setGeometry should justwork(tm)
> 
> Anthony Fieroni wrote:
> setGeometry *not* works, i can confirm since i'm test it. Nothing works 
> if Kwin is started *after* usage of kwindowsystem::self().
> Martin yeah nullprt is impossible.
> 
> Martin Gräßlin wrote:
> then this is a bug in Qt's xcb plugin and needs to be fixed there. 
> Setting a geometry without a window manager must be possible.
> 
> Anthony Fieroni wrote:
> Wait a little, the bug is not in xcb. I'm not clear or what. This 
> *happend* only on session restored apps, when kwindowsystem::self() is before 
> kwin statup, only in this case. If run a app after kwin is started *all* 
> works fine setGeometry(), move() - no problems.
> 
> Anthony Fieroni wrote:
> Thomas Lübking wrote:
>  The entire thing sounds as if the problem would be that the session 
> restorage in kwin overrides the placement for restored windows (with the 
> restored position)
>  
> For me, this is best explanation. Adn give you the easiest, no pain, 
> working solution - wait kwin to start completely.
> 
> Martin Gräßlin wrote:
> > Adn give you the easiest, no pain, working solution - wait kwin to 
> start completely.
> 
> I disagree. Working around such problems in the session startup seems 
> wrong. I would say excluse the sni windows from session restore, which can be 
> done from Qt API.
> 
> Thomas Lübking wrote:
> Can we please get few things straight?
> 
> You say that ::setGeometry doesn't work, but 
> https://git.reviewboard.kde.org/r/127216/diff/5#index_header makes use of it 
> (uses the propsed internally saved position and restores it with 
> QWidget::move what's basically a ::setGeometry special case)
> 
> => Does this work (leaving aside session restorage), yes or no?
> 
> Assuming it *does* work (except for session restorage) the claims to 
> require a WM for operative KWindowSystem invocation are gladfully, since 
> you're not using KWindowSystem at all.
> 
> 
> 
> Now onto session restorage:
> ---
> What exactly is the problem here?
> a) the windows are *not* visible when the session restarts. Showing them 
> show them in wrong position
> b) the windows *are* visible when the session restarts, but in wrong 
> position?
> 
> In either case, the session restored geometry and the SNI internal 
> geometry should *not* differ.
> 
> If they do there're two possible problems:
> 1. The window gets stored with the session, but the stored position is 
> wrong (check the

[Differential] [Closed] D1383: Fix crash on repainting an invalid sizes decoration

This revision was automatically updated to reflect the committed changes.
Closed by commit rKWIN0df4406c2cf8: Fix crash on repainting an invalid sizes 
decoration (authored by graesslin).

REPOSITORY
  rKWIN KWin

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D1383?vs=3273=3326

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

AFFECTED FILES
  autotests/wayland/CMakeLists.txt
  autotests/wayland/dont_crash_empty_deco.cpp
  client.h
  scene_opengl.cpp

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, Plasma, sebas
Cc: sebas, plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 127631: [ksmserver] We must be sure that kwin process is ended

2016-04-13 Thread Anthony Fieroni



> On Април 11, 2016, 8:45 преди обяд, Martin Gräßlin wrote:
> > > otherwise kwindowsystem::self() is nullptr
> > 
> > how can KWindowSystem::self() be null? And why should that have anything to 
> > do with KWin? KWindowSystem does not depend on a window manager running.
> 
> Thomas Lübking wrote:
> The entire thing sounds as if the problem would be that the session 
> restorage in kwin overrides the placement for restored windows (with the 
> restored position)
> 
> That's however not a bug (at least it's intended) and I've no idea why 
> that's relevant to the weird geometry handling of SNI items (which looks 
> *fr* too complex - the position of remapped windows is usually maintained 
> by QWidget ...)
> 
> Anthony Fieroni wrote:
> I saw the code, it looks like KWindowSystem not depend on Kwin, but Kwin 
> *must* be started *before* use of kwindowsystem. Thomas may right, because 
> setGeometry even not work on sessions restored app.
> When session was finish if start apps with kmail --session session-id 
> everything wors fine.
> 
> Anthony Fieroni wrote:
> Now, after Thomas comment, i even think only widget->show() must works 
> because widget has internal frameGeometry and position.
> 
> Martin Gräßlin wrote:
> > but Kwin must be started before use of kwindowsystem
> 
> no, really there is no reason for that. KWindowSystem doesn't depend on a 
> window manager running.
> 
> Anthony Fieroni wrote:
> Then, correct KWin to kwindowsystem to start working. If there is no bug 
> this will works on all cases -> https://git.reviewboard.kde.org/r/127216/ but 
> it's not.
> 
> Martin Gräßlin wrote:
> I don't know why you have problems, but it's impossible that 
> KWindowSystem::self() returns a nullptr. You can check the code to verify. 
> Something is really broken on your side, but I don't know what. Maybe missing 
> plugins installed?
> 
> Thomas Lübking wrote:
> it's not a hard dependecy on the instace, the sni geometry handling is 
> just plain broken.
> the workaround operates on configure events on the mapped window which 
> will go nowhere if there's no running wm.
> 
> the client needs to handle the no-wm case, ie. configure the window 
> correctly, but to repeat myself: such requirement implies that either sni or 
> qwidget/qwindow is completely fucked up.
> 
> qwindow/qwidget::setGeometry should justwork(tm)
> 
> Anthony Fieroni wrote:
> setGeometry *not* works, i can confirm since i'm test it. Nothing works 
> if Kwin is started *after* usage of kwindowsystem::self().
> Martin yeah nullprt is impossible.
> 
> Martin Gräßlin wrote:
> then this is a bug in Qt's xcb plugin and needs to be fixed there. 
> Setting a geometry without a window manager must be possible.
> 
> Anthony Fieroni wrote:
> Wait a little, the bug is not in xcb. I'm not clear or what. This 
> *happend* only on session restored apps, when kwindowsystem::self() is before 
> kwin statup, only in this case. If run a app after kwin is started *all* 
> works fine setGeometry(), move() - no problems.
> 
> Anthony Fieroni wrote:
> Thomas Lübking wrote:
>  The entire thing sounds as if the problem would be that the session 
> restorage in kwin overrides the placement for restored windows (with the 
> restored position)
>  
> For me, this is best explanation. Adn give you the easiest, no pain, 
> working solution - wait kwin to start completely.
> 
> Martin Gräßlin wrote:
> > Adn give you the easiest, no pain, working solution - wait kwin to 
> start completely.
> 
> I disagree. Working around such problems in the session startup seems 
> wrong. I would say excluse the sni windows from session restore, which can be 
> done from Qt API.
> 
> Thomas Lübking wrote:
> Can we please get few things straight?
> 
> You say that ::setGeometry doesn't work, but 
> https://git.reviewboard.kde.org/r/127216/diff/5#index_header makes use of it 
> (uses the propsed internally saved position and restores it with 
> QWidget::move what's basically a ::setGeometry special case)
> 
> => Does this work (leaving aside session restorage), yes or no?
> 
> Assuming it *does* work (except for session restorage) the claims to 
> require a WM for operative KWindowSystem invocation are gladfully, since 
> you're not using KWindowSystem at all.
> 
> 
> 
> Now onto session restorage:
> ---
> What exactly is the problem here?
> a) the windows are *not* visible when the session restarts. Showing them 
> show them in wrong position
> b) the windows *are* visible when the session restarts, but in wrong 
> position?
> 
> In either case, the session restored geometry and the SNI internal 
> geometry should *not* differ.
> 
> If they do there're two possible problems:
> 1. The window gets stored with the session, but the stored position is 
> wrong (check

[Powerdevil] [Bug 361708] System stuck in ac-plugged in mode ignoring Power management rules

2016-04-13 Thread Sudhir Khanger via KDE Bugzilla

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

--- Comment #1 from Sudhir Khanger  ---
Created attachment 98390
  --> https://bugs.kde.org/attachment.cgi?id=98390=edit
screenshot of the problem

-- 
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 127586: [calendar] Add a mark to days containing events

2016-04-13 Thread Martin Klapetek



> On April 13, 2016, 10:28 a.m., Marco Martin wrote:
> > what's the status of this?
> 
> Martin Klapetek wrote:
> Working on it.

Ok so I'm unable to render that svg, it is properly installed
and everything, but this doesn't show anything (not even error):

```
PlasmaCore.Svg {
id: calendarSvg
imagePath: "widgets/calendar"
}

PlasmaCore.SvgItem {
id: eventsMarker
width: parent.width / 3
height: parent.height / 3
svg: calendarSvg
elementId: "event"
}
```

...is it missing anything? If I use say "widgets/clock" and "ClockFace", it 
works fine.


- Martin


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


On April 6, 2016, 5:53 a.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127586/
> ---
> 
> (Updated April 6, 2016, 5:53 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> Simple triangle at the bottom right corner, see screenshot.
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/calendar/daysmodel.h 8ab232e 
>   src/declarativeimports/calendar/daysmodel.cpp bf99874 
>   src/declarativeimports/calendar/qml/DayDelegate.qml 6353827 
>   src/declarativeimports/calendar/qml/DaysCalendar.qml d4b8fe4 
> 
> Diff: https://git.reviewboard.kde.org/r/127586/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> Screenshot
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/04/06/afefe7ce-7757-4505-9f17-63fca2ec26cb__snapshot109.png
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

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

Re: Review Request 127646: Add a placement property to Menu and make use of it in a new openRelative() invokable


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

(Updated April 13, 2016, 9:23 p.m.)


Review request for Plasma.


Changes
---

Change API approach.


Summary (updated)
-

Add a placement property to Menu and make use of it in a new openRelative() 
invokable


Repository: plasma-framework


Description (updated)
---

This adds a property of Plasma::Types::PopupPlacement to Menu as well as an 
openRelative() method that implements alternative popup placement behavior, 
making use of the property value (which defaults to top-left). Whereas open(x, 
y) falls trough to traditional QMenu placement which will try to extend the 
menu past the bottom-right of the coordinates as much as it can (up to bumping 
against the screen edge, and possibly covering the visualParent), 
openRelative(placement) interprets the values of the PopupPlacement enum as 
requesting collision/alignment against the specified corner of the 
visualParent, allowing users of the item to avoid the menu covering the 
visualParent.

The Task Manager applet will use this to provide smart context menu placement 
for task items, as done in the past.

A property instead of a method parameter was used because it's not possible to 
use enums from a different class in method parameters in QML (QTBUG-20639).

An openRelative() was added instead of using the placement property if open() 
falls back to parameter default values to keep open() behavior unchanged.


Diffs (updated)
-

  src/declarativeimports/plasmacomponents/qmenu.h 34efe67 
  src/declarativeimports/plasmacomponents/qmenu.cpp 8ec1464 

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


Testing
---

Tested with rtl locales as well.


Thanks,

Eike Hein

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

Re: Review Request 127618: Applet : Display icons and device selection for streams

2016-04-13 Thread Yoann Laissus



> On avr. 9, 2016, 1:18 après-midi, David Rosca wrote:
> > The device combobox for streams was there (in my older review and also in 
> > much older version of sound applet), but it was decided to not show it in 
> > applet to keep it simple.
> > For the icons I have review (https://git.reviewboard.kde.org/r/127467/), 
> > but it needs to be reworked as it adds the icon property to Client, but it 
> > instead should be probably in PulseObject (as not every stream has Client).
> > I also think we should not show icon for devices in applet because almost 
> > all devices will have same icon (generic "audio-card"). Showing icon for 
> > Applicaton streams makes sense because hopefully all icons are different.
> > So -1 from me.
> > 
> > > Also, not related to this review, but what do you think about moving 
> > > sinkIndex and sourceIndex to a deviceIndex property in the Stream class ?
> > It would avoid to send an hardcoded deviceType to delegates.
> > 
> > Yes, that would indeed be much better.
> 
> Yoann Laissus wrote:
> > The device combobox for streams was there (in my older review and also 
> in much older version of sound applet), but it was decided to not show it in 
> applet to keep it simple.
> 
> Yes, you're right, after rethink that, most users will probably never 
> realize that stream entries can be expanded. It can be useful but not that 
> intuitive.
> In this case, maybe should we totally remove the sub component support in 
> ListItems ?
> 
> > For the icons I have review 
> (https://git.reviewboard.kde.org/r/127467/), but it needs to be reworked as 
> it adds the icon property to Client, but it instead should be probably in 
> PulseObject (as not every stream has Client).
> I also think we should not show icon for devices in applet because almost 
> all devices will have same icon (generic "audio-card"). Showing icon for 
> Applicaton streams makes sense because hopefully all icons are different.
> 
> Yes, it's a good idea to have the icon in PulseObject.
> 
> 
> I discard this review.
> 
> >> Also, not related to this review, but what do you think about moving 
> sinkIndex and sourceIndex to a deviceIndex property in the Stream class ? It 
> would avoid to send an hardcoded deviceType to delegates.
> 
> > Yes, that would indeed be much better.
> 
> I'll do another review for that.
> 
> David Rosca wrote:
> > In this case, maybe should we totally remove the sub component support 
> in ListItems ?
> 
> Yes, should be removed also with cleanup of all applet code. I plan to do 
> it eventually, but if you want, you can take it instead :)

Ok, I'll take care of that too ;)


- Yoann


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


On avr. 11, 2016, 11:19 matin, Yoann Laissus wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127618/
> ---
> 
> (Updated avr. 11, 2016, 11:19 matin)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-pa
> 
> 
> Description
> ---
> 
> The first commit fixes stream icons by using ClientIcon (like in the KCM).
> It also adds an icon for playback and capture devices to improve consistency 
> with the KCM.
> 
> The second commit adds, for each streams, the combobox used in the KCM to 
> select the device.
> 
> Branch here : 
> https://quickgit.kde.org/?p=clones%2Fplasma-pa%2Flaissus%2Fplasma-pa.git=shortlog=9eadc541cd55862b85399719904cbe85b4af1147
> 
> Also, not related to this review, but what do you think about moving 
> sinkIndex and sourceIndex to a deviceIndex property in the Stream class ?
> It would avoid to send an hardcoded deviceType to delegates.
> You can take a look at my first implementation (done before the introduction 
> of that in the KCM, dont' take care of the QML code) : 
> https://quickgit.kde.org/?p=clones%2Fplasma-pa%2Flaissus%2Fplasma-pa.git=commit=9d06be259f9438d2f489159b0b05b676fe26aacd
> 
> 
> Diffs
> -
> 
>   applet/contents/ui/ListItemBase.qml 
> d77d25a51b09149a1cf479eec0053184ae8625e6 
>   applet/contents/ui/StreamListItem.qml 
> 7e84505902ca116b466bcd408f00ecaa9a4ce8da 
>   applet/contents/ui/main.qml 086716d739e5c67ccabfceaca4fea86fd40cc8a0 
>   src/kcm/package/contents/ui/DeviceComboBox.qml  
>   src/qml/CMakeLists.txt 9d021fcf61e4820efd0623060381dea0d7c30506 
>   src/qml/ClientIcon.qml 8256758048907fd8bf62f5d6e7a7176e1855c1e8 
>   src/qml/qmldir de44fca76deb79017be8c3033d1eb462242145e8 
> 
> Diff: https://git.reviewboard.kde.org/r/127618/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> Streams
>   
>

Re: Review Request 127646: Add parameter to request collision detection against supplied menu coordinates



> On April 13, 2016, 6:43 p.m., Marco Martin wrote:
> > I don't like the api...
> > If I understand correctly you need the menu aligned with the task item not 
> > going over the taskbar also in cases of windows can cover?
> > I would prefer in this case another open method, something along the lines 
> > of open(Plasma::Types::Location) that would open the menu relative to the 
> > visualparent, aligning it depending on the location
> 
> Eike Hein wrote:
> No, it has nothing to do with the panel or even the visual parent. By 
> default QMenus open towards the bottom and right of $pos. If $pos is closer 
> to the bottom or right of the screen than the menu is big, the menu will go 
> as far bottom and right as it can, bumping against the screen edge. In the 
> case of the Task Manager that means the menu covers the task button. Our Task 
> Managers have always had code to avoid this and position the context menu 
> either against the panel edge or (better, because of multi-row task managers) 
> the task item. The old Task Manager applet had the same code I added here to 
> accomplish this.
> 
> Your API suggestion is OK, but in some sense kind of doesn't overlap with 
> this one. Your proposal would add a new API to position the menu relative to 
> the visual parent with the Location enum (which I personally always felt is 
> very very confusing, but I digress). This extends the coordinate-based API 
> with a hint for how those coordinates should be respected.
> 
> Eike Hein wrote:
> Note: I can try writing the enum API if you still want me to though ...
> 
> Marco Martin wrote:
> the task item would be the visual parent, no?
> 
> Eike Hein wrote:
> Yeah. The enum-based API would address the use case as well, but 
> strictly-speaking the coordinate-based API could still benefit from this if 
> someone prefers to use it.
> 
> I'm fine with implementing either as you see fit.
> 
> Though it's noteworthy that the Location enum is kind of broken by design 
> for specifying relative positions, because it makes it hard to specify 
> corners. You can do Left/Right/Top/Bottom, but you can't | the values to 
> combine, say, Right and Bottom because it's not a flag enum. That means you 
> have to bake in the assumption that Bottom means bottom-left. The 
> coordinate-based API doesn't suffer from this restriction since you can just 
> pass any coordinates in the visualParent. If we ever break Plasma API we 
> should add a Position enum and convert all the relevant APIs to it.
> 
> Eike Hein wrote:
> I just noticed we have a PopupPlacement enum actually ...
> 
> Marco Martin wrote:
> would the popupplacement values describe what you need?
> would go with that then

Did it, but looks like I have to do a prop after all, as a method parameter 
doesn't work:

plasmashell(27748)/default unknown: 
file:///home/eike/devel/install/share/plasma/plasmoids/org.kde.plasma.taskmanagerng/contents/ui/ContextMenu.qml:51:
 Error: Unknown method parameter type: Plasma::Types::PopupPlacement

https://bugreports.qt.io/browse/QTBUG-20639


- Eike


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


On April 13, 2016, 5:24 p.m., Eike Hein wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127646/
> ---
> 
> (Updated April 13, 2016, 5:24 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> This adds a parameter to open() to request the menu be positioned to collide 
> against the supplied coordinates instead of the screen edge if there's 
> insufficient space to show the entire menu next to the coordinates. This 
> allows Task Manager-style positioning (which used to be hardcoded in C++ in 
> the applet), where the menu is shown above a task item in a bottom panel and 
> to the left of the task item in a right panel. Without this opt-in behavior, 
> the menu goes as far below/right of the coordinates as it an until it 
> collides with the screen edge, therefore overlapping with the item.
> 
> The new behavior defaults to off, to not change API behavior.
> 
> It's added as a new parameter instead of a declarative prop in keeping with 
> the existing style - the open coordinates are not declarative either; the 
> whole thing is treated as a one-shot procedural op.
> 
> This will be used by the Task Manager applet to position the task context 
> menu more smartly.
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/plasmacomponents/qmenu.h 41e8865 
>   src/declarativeimports/plasmacomponents/qmenu.cpp 2a96d77 
> 
> Diff: https://git.reviewboard.kde.org/r/127646/diff/
> 
> 
>

Re: Review Request 127646: Add parameter to request collision detection against supplied menu coordinates



> On April 13, 2016, 6:43 p.m., Marco Martin wrote:
> > I don't like the api...
> > If I understand correctly you need the menu aligned with the task item not 
> > going over the taskbar also in cases of windows can cover?
> > I would prefer in this case another open method, something along the lines 
> > of open(Plasma::Types::Location) that would open the menu relative to the 
> > visualparent, aligning it depending on the location
> 
> Eike Hein wrote:
> No, it has nothing to do with the panel or even the visual parent. By 
> default QMenus open towards the bottom and right of $pos. If $pos is closer 
> to the bottom or right of the screen than the menu is big, the menu will go 
> as far bottom and right as it can, bumping against the screen edge. In the 
> case of the Task Manager that means the menu covers the task button. Our Task 
> Managers have always had code to avoid this and position the context menu 
> either against the panel edge or (better, because of multi-row task managers) 
> the task item. The old Task Manager applet had the same code I added here to 
> accomplish this.
> 
> Your API suggestion is OK, but in some sense kind of doesn't overlap with 
> this one. Your proposal would add a new API to position the menu relative to 
> the visual parent with the Location enum (which I personally always felt is 
> very very confusing, but I digress). This extends the coordinate-based API 
> with a hint for how those coordinates should be respected.
> 
> Eike Hein wrote:
> Note: I can try writing the enum API if you still want me to though ...
> 
> Marco Martin wrote:
> the task item would be the visual parent, no?
> 
> Eike Hein wrote:
> Yeah. The enum-based API would address the use case as well, but 
> strictly-speaking the coordinate-based API could still benefit from this if 
> someone prefers to use it.
> 
> I'm fine with implementing either as you see fit.
> 
> Though it's noteworthy that the Location enum is kind of broken by design 
> for specifying relative positions, because it makes it hard to specify 
> corners. You can do Left/Right/Top/Bottom, but you can't | the values to 
> combine, say, Right and Bottom because it's not a flag enum. That means you 
> have to bake in the assumption that Bottom means bottom-left. The 
> coordinate-based API doesn't suffer from this restriction since you can just 
> pass any coordinates in the visualParent. If we ever break Plasma API we 
> should add a Position enum and convert all the relevant APIs to it.

I just noticed we have a PopupPlacement enum actually ...


- Eike


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


On April 13, 2016, 5:24 p.m., Eike Hein wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127646/
> ---
> 
> (Updated April 13, 2016, 5:24 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> This adds a parameter to open() to request the menu be positioned to collide 
> against the supplied coordinates instead of the screen edge if there's 
> insufficient space to show the entire menu next to the coordinates. This 
> allows Task Manager-style positioning (which used to be hardcoded in C++ in 
> the applet), where the menu is shown above a task item in a bottom panel and 
> to the left of the task item in a right panel. Without this opt-in behavior, 
> the menu goes as far below/right of the coordinates as it an until it 
> collides with the screen edge, therefore overlapping with the item.
> 
> The new behavior defaults to off, to not change API behavior.
> 
> It's added as a new parameter instead of a declarative prop in keeping with 
> the existing style - the open coordinates are not declarative either; the 
> whole thing is treated as a one-shot procedural op.
> 
> This will be used by the Task Manager applet to position the task context 
> menu more smartly.
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/plasmacomponents/qmenu.h 41e8865 
>   src/declarativeimports/plasmacomponents/qmenu.cpp 2a96d77 
> 
> Diff: https://git.reviewboard.kde.org/r/127646/diff/
> 
> 
> Testing
> ---
> 
> Tested with rtl locales as well.
> 
> 
> Thanks,
> 
> Eike Hein
> 
>

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

Re: Review Request 127646: Add parameter to request collision detection against supplied menu coordinates



> On April 13, 2016, 6:43 p.m., Marco Martin wrote:
> > I don't like the api...
> > If I understand correctly you need the menu aligned with the task item not 
> > going over the taskbar also in cases of windows can cover?
> > I would prefer in this case another open method, something along the lines 
> > of open(Plasma::Types::Location) that would open the menu relative to the 
> > visualparent, aligning it depending on the location
> 
> Eike Hein wrote:
> No, it has nothing to do with the panel or even the visual parent. By 
> default QMenus open towards the bottom and right of $pos. If $pos is closer 
> to the bottom or right of the screen than the menu is big, the menu will go 
> as far bottom and right as it can, bumping against the screen edge. In the 
> case of the Task Manager that means the menu covers the task button. Our Task 
> Managers have always had code to avoid this and position the context menu 
> either against the panel edge or (better, because of multi-row task managers) 
> the task item. The old Task Manager applet had the same code I added here to 
> accomplish this.
> 
> Your API suggestion is OK, but in some sense kind of doesn't overlap with 
> this one. Your proposal would add a new API to position the menu relative to 
> the visual parent with the Location enum (which I personally always felt is 
> very very confusing, but I digress). This extends the coordinate-based API 
> with a hint for how those coordinates should be respected.
> 
> Eike Hein wrote:
> Note: I can try writing the enum API if you still want me to though ...
> 
> Marco Martin wrote:
> the task item would be the visual parent, no?

Yeah. The enum-based API would address the use case as well, but 
strictly-speaking the coordinate-based API could still benefit from this if 
someone prefers to use it.

I'm fine with implementing either as you see fit.

Though it's noteworthy that the Location enum is kind of broken by design for 
specifying relative positions, because it makes it hard to specify corners. You 
can do Left/Right/Top/Bottom, but you can't | the values to combine, say, Right 
and Bottom because it's not a flag enum. That means you have to bake in the 
assumption that Bottom means bottom-left. The coordinate-based API doesn't 
suffer from this restriction since you can just pass any coordinates in the 
visualParent. If we ever break Plasma API we should add a Position enum and 
convert all the relevant APIs to it.


- Eike


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


On April 13, 2016, 5:24 p.m., Eike Hein wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127646/
> ---
> 
> (Updated April 13, 2016, 5:24 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> This adds a parameter to open() to request the menu be positioned to collide 
> against the supplied coordinates instead of the screen edge if there's 
> insufficient space to show the entire menu next to the coordinates. This 
> allows Task Manager-style positioning (which used to be hardcoded in C++ in 
> the applet), where the menu is shown above a task item in a bottom panel and 
> to the left of the task item in a right panel. Without this opt-in behavior, 
> the menu goes as far below/right of the coordinates as it an until it 
> collides with the screen edge, therefore overlapping with the item.
> 
> The new behavior defaults to off, to not change API behavior.
> 
> It's added as a new parameter instead of a declarative prop in keeping with 
> the existing style - the open coordinates are not declarative either; the 
> whole thing is treated as a one-shot procedural op.
> 
> This will be used by the Task Manager applet to position the task context 
> menu more smartly.
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/plasmacomponents/qmenu.h 41e8865 
>   src/declarativeimports/plasmacomponents/qmenu.cpp 2a96d77 
> 
> Diff: https://git.reviewboard.kde.org/r/127646/diff/
> 
> 
> Testing
> ---
> 
> Tested with rtl locales as well.
> 
> 
> Thanks,
> 
> Eike Hein
> 
>

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

Re: Review Request 127646: Add parameter to request collision detection against supplied menu coordinates



> On April 13, 2016, 6:43 p.m., Marco Martin wrote:
> > I don't like the api...
> > If I understand correctly you need the menu aligned with the task item not 
> > going over the taskbar also in cases of windows can cover?
> > I would prefer in this case another open method, something along the lines 
> > of open(Plasma::Types::Location) that would open the menu relative to the 
> > visualparent, aligning it depending on the location
> 
> Eike Hein wrote:
> No, it has nothing to do with the panel or even the visual parent. By 
> default QMenus open towards the bottom and right of $pos. If $pos is closer 
> to the bottom or right of the screen than the menu is big, the menu will go 
> as far bottom and right as it can, bumping against the screen edge. In the 
> case of the Task Manager that means the menu covers the task button. Our Task 
> Managers have always had code to avoid this and position the context menu 
> either against the panel edge or (better, because of multi-row task managers) 
> the task item. The old Task Manager applet had the same code I added here to 
> accomplish this.
> 
> Your API suggestion is OK, but in some sense kind of doesn't overlap with 
> this one. Your proposal would add a new API to position the menu relative to 
> the visual parent with the Location enum (which I personally always felt is 
> very very confusing, but I digress). This extends the coordinate-based API 
> with a hint for how those coordinates should be respected.
> 
> Eike Hein wrote:
> Note: I can try writing the enum API if you still want me to though ...

the task item would be the visual parent, no?


- Marco


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


On April 13, 2016, 5:24 p.m., Eike Hein wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127646/
> ---
> 
> (Updated April 13, 2016, 5:24 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> This adds a parameter to open() to request the menu be positioned to collide 
> against the supplied coordinates instead of the screen edge if there's 
> insufficient space to show the entire menu next to the coordinates. This 
> allows Task Manager-style positioning (which used to be hardcoded in C++ in 
> the applet), where the menu is shown above a task item in a bottom panel and 
> to the left of the task item in a right panel. Without this opt-in behavior, 
> the menu goes as far below/right of the coordinates as it an until it 
> collides with the screen edge, therefore overlapping with the item.
> 
> The new behavior defaults to off, to not change API behavior.
> 
> It's added as a new parameter instead of a declarative prop in keeping with 
> the existing style - the open coordinates are not declarative either; the 
> whole thing is treated as a one-shot procedural op.
> 
> This will be used by the Task Manager applet to position the task context 
> menu more smartly.
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/plasmacomponents/qmenu.h 41e8865 
>   src/declarativeimports/plasmacomponents/qmenu.cpp 2a96d77 
> 
> Diff: https://git.reviewboard.kde.org/r/127646/diff/
> 
> 
> Testing
> ---
> 
> Tested with rtl locales as well.
> 
> 
> Thanks,
> 
> Eike Hein
> 
>

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

[Powerdevil] [Bug 357288] Setting "Screen Energy Saving" in "Energy Saving" config has no effect

2016-04-13 Thread Jake Cobb via KDE Bugzilla

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

--- Comment #3 from Jake Cobb  ---
For some further information, allowing the screen to lock from the power
management settings will wake it back up when the screen locks.

Specifically, Desktop Behavior > Screen Locking is off.  Power Management >
Energy Saving has:
-Screen Energy Saving checked, Switch off after 1 min.
-Suspend session checked, After 2 min Lock screen.

Then the monitor sleeps after one minute but turns back on with the lock screen
after the second minute.

-- 
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 127646: Add parameter to request collision detection against supplied menu coordinates



> On April 13, 2016, 6:43 p.m., Marco Martin wrote:
> > I don't like the api...
> > If I understand correctly you need the menu aligned with the task item not 
> > going over the taskbar also in cases of windows can cover?
> > I would prefer in this case another open method, something along the lines 
> > of open(Plasma::Types::Location) that would open the menu relative to the 
> > visualparent, aligning it depending on the location
> 
> Eike Hein wrote:
> No, it has nothing to do with the panel or even the visual parent. By 
> default QMenus open towards the bottom and right of $pos. If $pos is closer 
> to the bottom or right of the screen than the menu is big, the menu will go 
> as far bottom and right as it can, bumping against the screen edge. In the 
> case of the Task Manager that means the menu covers the task button. Our Task 
> Managers have always had code to avoid this and position the context menu 
> either against the panel edge or (better, because of multi-row task managers) 
> the task item. The old Task Manager applet had the same code I added here to 
> accomplish this.
> 
> Your API suggestion is OK, but in some sense kind of doesn't overlap with 
> this one. Your proposal would add a new API to position the menu relative to 
> the visual parent with the Location enum (which I personally always felt is 
> very very confusing, but I digress). This extends the coordinate-based API 
> with a hint for how those coordinates should be respected.

Note: I can try writing the enum API if you still want me to though ...


- Eike


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


On April 13, 2016, 5:24 p.m., Eike Hein wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127646/
> ---
> 
> (Updated April 13, 2016, 5:24 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> This adds a parameter to open() to request the menu be positioned to collide 
> against the supplied coordinates instead of the screen edge if there's 
> insufficient space to show the entire menu next to the coordinates. This 
> allows Task Manager-style positioning (which used to be hardcoded in C++ in 
> the applet), where the menu is shown above a task item in a bottom panel and 
> to the left of the task item in a right panel. Without this opt-in behavior, 
> the menu goes as far below/right of the coordinates as it an until it 
> collides with the screen edge, therefore overlapping with the item.
> 
> The new behavior defaults to off, to not change API behavior.
> 
> It's added as a new parameter instead of a declarative prop in keeping with 
> the existing style - the open coordinates are not declarative either; the 
> whole thing is treated as a one-shot procedural op.
> 
> This will be used by the Task Manager applet to position the task context 
> menu more smartly.
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/plasmacomponents/qmenu.h 41e8865 
>   src/declarativeimports/plasmacomponents/qmenu.cpp 2a96d77 
> 
> Diff: https://git.reviewboard.kde.org/r/127646/diff/
> 
> 
> Testing
> ---
> 
> Tested with rtl locales as well.
> 
> 
> Thanks,
> 
> Eike Hein
> 
>

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

Re: Review Request 127648: Allow setting a minimum width on the menu


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

(Updated April 13, 2016, 7:22 p.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma.


Changes
---

Submitted with commit 17cea8059e5a09ff972f251e631e3e57476a1da2 by Eike Hein to 
branch master.


Repository: plasma-framework


Description
---

This adds a new prop to allow setting a minimum width for the menu. This allows 
to e.g. make a menu at least as wide as its visual parent item, if so desired 
for aesthetic reasons.

This will be used by the Task Manager applet to make task context menus at 
least as wide as the task item (a longstanding tweak found in older 
implementations).


Diffs
-

  src/declarativeimports/plasmacomponents/qmenu.h 41e8865 
  src/declarativeimports/plasmacomponents/qmenu.cpp 2a96d77 

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


Testing
---


Thanks,

Eike Hein

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

Re: Review Request 127646: Add parameter to request collision detection against supplied menu coordinates

> On April 13, 2016, 6:43 p.m., Marco Martin wrote:
> > I don't like the api...
> > If I understand correctly you need the menu aligned with the task item not 
> > going over the taskbar also in cases of windows can cover?
> > I would prefer in this case another open method, something along the lines 
> > of open(Plasma::Types::Location) that would open the menu relative to the 
> > visualparent, aligning it depending on the location

No, it has nothing to do with the panel or even the visual parent. By default 
QMenus open towards the bottom and right of $pos. If $pos is closer to the 
bottom or right of the screen than the menu is big, the menu will go as far 
bottom and right as it can, bumping against the screen edge. In the case of the 
Task Manager that means the menu covers the task button. Our Task Managers have 
always had code to avoid this and position the context menu either against the 
panel edge or (better, because of multi-row task managers) the task item. The 
old Task Manager applet had the same code I added here to accomplish this.

Your API suggestion is OK, but in some sense kind of doesn't overlap with this 
one. Your proposal would add a new API to position the menu relative to the 
visual parent with the Location enum (which I personally always felt is very 
very confusing, but I digress). This extends the coordinate-based API with a 
hint for how those coordinates should be respected.

- Eike

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

On April 13, 2016, 5:24 p.m., Eike Hein wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127646/
> ---
> 
> (Updated April 13, 2016, 5:24 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> This adds a parameter to open() to request the menu be positioned to collide 
> against the supplied coordinates instead of the screen edge if there's 
> insufficient space to show the entire menu next to the coordinates. This 
> allows Task Manager-style positioning (which used to be hardcoded in C++ in 
> the applet), where the menu is shown above a task item in a bottom panel and 
> to the left of the task item in a right panel. Without this opt-in behavior, 
> the menu goes as far below/right of the coordinates as it an until it 
> collides with the screen edge, therefore overlapping with the item.
> 
> The new behavior defaults to off, to not change API behavior.
> 
> It's added as a new parameter instead of a declarative prop in keeping with 
> the existing style - the open coordinates are not declarative either; the 
> whole thing is treated as a one-shot procedural op.
> 
> This will be used by the Task Manager applet to position the task context 
> menu more smartly.
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/plasmacomponents/qmenu.h 41e8865 
>   src/declarativeimports/plasmacomponents/qmenu.cpp 2a96d77 
> 
> Diff: https://git.reviewboard.kde.org/r/127646/diff/
> 
> 
> Testing
> ---
> 
> Tested with rtl locales as well.
> 
> 
> Thanks,
> 
> Eike Hein
> 
>

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

Re: Review Request 127646: Add parameter to request collision detection against supplied menu coordinates


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



I don't like the api...
If I understand correctly you need the menu aligned with the task item not 
going over the taskbar also in cases of windows can cover?
I would prefer in this case another open method, something along the lines of 
open(Plasma::Types::Location) that would open the menu relative to the 
visualparent, aligning it depending on the location

- Marco Martin


On April 13, 2016, 5:24 p.m., Eike Hein wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127646/
> ---
> 
> (Updated April 13, 2016, 5:24 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> This adds a parameter to open() to request the menu be positioned to collide 
> against the supplied coordinates instead of the screen edge if there's 
> insufficient space to show the entire menu next to the coordinates. This 
> allows Task Manager-style positioning (which used to be hardcoded in C++ in 
> the applet), where the menu is shown above a task item in a bottom panel and 
> to the left of the task item in a right panel. Without this opt-in behavior, 
> the menu goes as far below/right of the coordinates as it an until it 
> collides with the screen edge, therefore overlapping with the item.
> 
> The new behavior defaults to off, to not change API behavior.
> 
> It's added as a new parameter instead of a declarative prop in keeping with 
> the existing style - the open coordinates are not declarative either; the 
> whole thing is treated as a one-shot procedural op.
> 
> This will be used by the Task Manager applet to position the task context 
> menu more smartly.
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/plasmacomponents/qmenu.h 41e8865 
>   src/declarativeimports/plasmacomponents/qmenu.cpp 2a96d77 
> 
> Diff: https://git.reviewboard.kde.org/r/127646/diff/
> 
> 
> Testing
> ---
> 
> Tested with rtl locales as well.
> 
> 
> Thanks,
> 
> Eike Hein
> 
>

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

Re: Review Request 127648: Allow setting a minimum width on the menu


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


Ship it!




Ship It!

- Marco Martin


On April 13, 2016, 5:37 p.m., Eike Hein wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127648/
> ---
> 
> (Updated April 13, 2016, 5:37 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> This adds a new prop to allow setting a minimum width for the menu. This 
> allows to e.g. make a menu at least as wide as its visual parent item, if so 
> desired for aesthetic reasons.
> 
> This will be used by the Task Manager applet to make task context menus at 
> least as wide as the task item (a longstanding tweak found in older 
> implementations).
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/plasmacomponents/qmenu.h 41e8865 
>   src/declarativeimports/plasmacomponents/qmenu.cpp 2a96d77 
> 
> Diff: https://git.reviewboard.kde.org/r/127648/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Eike Hein
> 
>

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

Re: Review Request 123653: New Minimize Windows Plasmoid

2016-04-13 Thread Anthony Fieroni


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



This applet is *must have* for many users, let's make'm happy :) => 
http://kde-look.org/content/show.php/Minimize+All?content=175817

- Anthony Fieroni


On Авг. 25, 2015, 1:41 след обяд, Sebastian Kügler wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123653/
> ---
> 
> (Updated Авг. 25, 2015, 1:41 след обяд)
> 
> 
> Review request for Plasma.
> 
> 
> Bugs: 346837
> http://bugs.kde.org/show_bug.cgi?id=346837
> 
> 
> Repository: kdeplasma-addons
> 
> 
> Description
> ---
> 
> New Minimize Windows Plasmoid
> 
> This plasmoid allows to minimize windows on the current desktop. It does
> not mess with the KWindowSystem::showingDesktop flag, just allows to hide
> and show windows.
> 
> 
> Diffs
> -
> 
>   applets/CMakeLists.txt 7ada7ac 
>   applets/minimizeall/CMakeLists.txt PRE-CREATION 
>   applets/minimizeall/Messages.sh PRE-CREATION 
>   applets/minimizeall/package/contents/config/main.xml PRE-CREATION 
>   applets/minimizeall/package/contents/ui/main.qml PRE-CREATION 
>   applets/minimizeall/package/metadata.desktop PRE-CREATION 
>   applets/minimizeall/plugin/minimizeall.h PRE-CREATION 
>   applets/minimizeall/plugin/minimizeall.cpp PRE-CREATION 
>   applets/minimizeall/plugin/minimizeallplugin.h PRE-CREATION 
>   applets/minimizeall/plugin/minimizeallplugin.cpp PRE-CREATION 
>   applets/minimizeall/plugin/qmldir PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/123653/diff/
> 
> 
> Testing
> ---
> 
> Used it for a while.
> 
> 
> Thanks,
> 
> Sebastian Kügler
> 
>

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

Review Request 127648: Allow setting a minimum width on the menu


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

Review request for Plasma.


Repository: plasma-framework


Description
---

This adds a new prop to allow setting a minimum width for the menu. This allows 
to e.g. make a menu at least as wide as its visual parent item, if so desired 
for aesthetic reasons.

This will be used by the Task Manager applet to make task context menus at 
least as wide as the task item (a longstanding tweak found in older 
implementations).


Diffs
-

  src/declarativeimports/plasmacomponents/qmenu.h 41e8865 
  src/declarativeimports/plasmacomponents/qmenu.cpp 2a96d77 

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


Testing
---


Thanks,

Eike Hein

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

Review Request 127646: Add parameter to request collision detection against supplied menu coordinates


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

Review request for Plasma.


Repository: plasma-framework


Description
---

This adds a parameter to open() to request the menu be positioned to collide 
against the supplied coordinates instead of the screen edge if there's 
insufficient space to show the entire menu next to the coordinates. This allows 
Task Manager-style positioning (which used to be hardcoded in C++ in the 
applet), where the menu is shown above a task item in a bottom panel and to the 
left of the task item in a right panel. Without this opt-in behavior, the menu 
goes as far below/right of the coordinates as it an until it collides with the 
screen edge, therefore overlapping with the item.

The new behavior defaults to off, to not change API behavior.

It's added as a new parameter instead of a declarative prop in keeping with the 
existing style - the open coordinates are not declarative either; the whole 
thing is treated as a one-shot procedural op.

This will be used by the Task Manager applet to position the task context menu 
more smartly.


Diffs
-

  src/declarativeimports/plasmacomponents/qmenu.h 41e8865 
  src/declarativeimports/plasmacomponents/qmenu.cpp 2a96d77 

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


Testing
---

Tested with rtl locales as well.


Thanks,

Eike Hein

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

Re: Review Request 127640: Update desktopthemedetails docbook to 5.6

2016-04-13 Thread Burkhard Lück


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

(Updated April 13, 2016, 9:57 a.m.)


Status
--

This change has been marked as submitted.


Review request for Documentation and Plasma.


Changes
---

Submitted with commit 98873732cb0d6fd5d47452e0e5d853e87e7adc5a by Burkhard Lück 
to branch master.


Repository: plasma-desktop


Description
---

Remove Info about Details tab and how to configure single components of a 
theme, feature was removed in 5.6

Add note to inform users about removed feature to avoid confusion for users, 
see e.g https://forum.kde.org/viewtopic.php?f=17=132011  

Add link to techbase page with info about themedetails

Add recommended tool


Diffs
-

  doc/kcontrol/desktopthemedetails/customizing.png 4ac18a1 
  doc/kcontrol/desktopthemedetails/index.docbook 2cfa55a 

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


Testing
---

passes checkXML5


Thanks,

Burkhard Lück

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

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

2016-04-13 Thread no-reply


GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/plasma-workspace%20Plasma-5.6%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/22/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Wed, 13 Apr 2016 16:39:43 +
Build duration: 7 min 25 sec

CHANGE SET
No changes


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 9/9 (100%)FILES 42/47 (89%)CLASSES 42/47 (89%)LINE 1661/2088 
(80%)CONDITIONAL 1206/1802 (67%)

By packages
  
drkonqi.parser
FILES 6/10 (60%)CLASSES 6/10 (60%)LINE 303/423 (72%)CONDITIONAL 
478/541 (88%)
drkonqi.tests.backtraceparsertest
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 74/74 (100%)CONDITIONAL 
33/50 (66%)
kioslave.desktop
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 90/131 (69%)CONDITIONAL 
34/50 (68%)
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 256/384 
(67%)CONDITIONAL 109/146 (75%)
klipper.autotests
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 630/693 (91%)CONDITIONAL 
377/742 (51%)
runners.bookmarks
FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 89/159 (56%)CONDITIONAL 
34/56 (61%)
runners.bookmarks.browsers
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 88/93 (95%)CONDITIONAL 
84/107 (79%)
runners.bookmarks.tests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 65/65 (100%)CONDITIONAL 
31/60 (52%)___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

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

2016-04-13 Thread no-reply


GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/plasma-workspace%20Plasma-5.6%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/22/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Wed, 13 Apr 2016 16:39:43 +
Build duration: 7 min 25 sec

CHANGE SET
No changes


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 9/9 (100%)FILES 42/47 (89%)CLASSES 42/47 (89%)LINE 1661/2088 
(80%)CONDITIONAL 1206/1802 (67%)

By packages
  
drkonqi.parser
FILES 6/10 (60%)CLASSES 6/10 (60%)LINE 303/423 (72%)CONDITIONAL 
478/541 (88%)
drkonqi.tests.backtraceparsertest
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 74/74 (100%)CONDITIONAL 
33/50 (66%)
kioslave.desktop
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 90/131 (69%)CONDITIONAL 
34/50 (68%)
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 256/384 
(67%)CONDITIONAL 109/146 (75%)
klipper.autotests
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 630/693 (91%)CONDITIONAL 
377/742 (51%)
runners.bookmarks
FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 89/159 (56%)CONDITIONAL 
34/56 (61%)
runners.bookmarks.browsers
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 88/93 (95%)CONDITIONAL 
84/107 (79%)
runners.bookmarks.tests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 65/65 (100%)CONDITIONAL 
31/60 (52%)___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 127645: Add overload for adding a MenuItem at a specific position


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

(Updated April 13, 2016, 9:17 a.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma.


Changes
---

Submitted with commit 70301e21b99c8cc476a151e12cd4ee07c8b6598c by Eike Hein to 
branch master.


Repository: plasma-framework


Description
---

This adds a second MenuItem parameter to addMenuItem, which is used as a 
position reference for inserting the new item.

The resulting API matches QWidget::insertAction in spirit.

Implicitly allows reordering items in the menu by removing and reinserting if 
an item already exists (adding actions multiple times was already not supported 
due to "A QWidget should only have one of each action and adding an action it 
already has will not cause the same action to be in the widget twice." in the 
underlying implementation). This is actually quite useful because it aligns 
well with parenting a PlasmaComponents.MenuItem initially to the menu via 
Qt.createQmlObject(), then moving it into the desired place before opening the 
menu.

This will be used by the Task Manager applet for dynamically adding actions for 
recent docs and jump list actions to a task context menu.


Diffs
-

  src/declarativeimports/plasmacomponents/qmenu.h baee963 
  src/declarativeimports/plasmacomponents/qmenu.cpp d84f481 

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


Testing
---


Thanks,

Eike Hein

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

Re: Review Request 127645: Add overload for adding a MenuItem at a specific position


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


Ship it!




Ship It!

- Marco Martin


On April 13, 2016, 4:15 p.m., Eike Hein wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127645/
> ---
> 
> (Updated April 13, 2016, 4:15 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> This adds a second MenuItem parameter to addMenuItem, which is used as a 
> position reference for inserting the new item.
> 
> The resulting API matches QWidget::insertAction in spirit.
> 
> Implicitly allows reordering items in the menu by removing and reinserting if 
> an item already exists (adding actions multiple times was already not 
> supported due to "A QWidget should only have one of each action and adding an 
> action it already has will not cause the same action to be in the widget 
> twice." in the underlying implementation). This is actually quite useful 
> because it aligns well with parenting a PlasmaComponents.MenuItem initially 
> to the menu via Qt.createQmlObject(), then moving it into the desired place 
> before opening the menu.
> 
> This will be used by the Task Manager applet for dynamically adding actions 
> for recent docs and jump list actions to a task context menu.
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/plasmacomponents/qmenu.h baee963 
>   src/declarativeimports/plasmacomponents/qmenu.cpp d84f481 
> 
> Diff: https://git.reviewboard.kde.org/r/127645/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Eike Hein
> 
>

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

Re: Review Request 127645: Add overload for adding a MenuItem at a specific position


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

(Updated April 13, 2016, 4:15 p.m.)


Review request for Plasma.


Changes
---

Drop debug


Repository: plasma-framework


Description
---

This adds a second MenuItem parameter to addMenuItem, which is used as a 
position reference for inserting the new item.

The resulting API matches QWidget::insertAction in spirit.

Implicitly allows reordering items in the menu by removing and reinserting if 
an item already exists (adding actions multiple times was already not supported 
due to "A QWidget should only have one of each action and adding an action it 
already has will not cause the same action to be in the widget twice." in the 
underlying implementation). This is actually quite useful because it aligns 
well with parenting a PlasmaComponents.MenuItem initially to the menu via 
Qt.createQmlObject(), then moving it into the desired place before opening the 
menu.

This will be used by the Task Manager applet for dynamically adding actions for 
recent docs and jump list actions to a task context menu.


Diffs (updated)
-

  src/declarativeimports/plasmacomponents/qmenu.h baee963 
  src/declarativeimports/plasmacomponents/qmenu.cpp d84f481 

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


Testing
---


Thanks,

Eike Hein

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

Re: Review Request 127645: Add overload for adding a MenuItem at a specific position


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

(Updated April 13, 2016, 4:13 p.m.)


Review request for Plasma.


Changes
---

Drop overload; Marco points out we can break BC at will here.


Repository: plasma-framework


Description (updated)
---

This adds a second MenuItem parameter to addMenuItem, which is used as a 
position reference for inserting the new item.

The resulting API matches QWidget::insertAction in spirit.

Implicitly allows reordering items in the menu by removing and reinserting if 
an item already exists (adding actions multiple times was already not supported 
due to "A QWidget should only have one of each action and adding an action it 
already has will not cause the same action to be in the widget twice." in the 
underlying implementation). This is actually quite useful because it aligns 
well with parenting a PlasmaComponents.MenuItem initially to the menu via 
Qt.createQmlObject(), then moving it into the desired place before opening the 
menu.

This will be used by the Task Manager applet for dynamically adding actions for 
recent docs and jump list actions to a task context menu.


Diffs (updated)
-

  src/declarativeimports/plasmacomponents/qmenu.h baee963 
  src/declarativeimports/plasmacomponents/qmenu.cpp d84f481 

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


Testing
---


Thanks,

Eike Hein

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

Re: Review Request 127645: Add overload for adding a MenuItem at a specific position


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


Fix it, then Ship it!





src/declarativeimports/plasmacomponents/qmenu.h (line 129)


is not a public library, so the default argument is fine here


- Marco Martin


On April 13, 2016, 4:07 p.m., Eike Hein wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127645/
> ---
> 
> (Updated April 13, 2016, 4:07 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> This adds a new addMenuItem overload accepting a different MenuItem instance 
> as second parameter, which is used as a position reference for inserting the 
> new item.
> 
> This matches QWidget::insertAction in spirit.
> 
> Implicitly allows reordering items in the menu by removing and reinserting if 
> an item already exists (adding actions multiple times was already not 
> supported due to "A QWidget should only have one of each action and adding an 
> action it already has will not cause the same action to be in the widget 
> twice." in the underlying implementation). This is actually quite useful 
> because it aligns well with parenting a PlasmaComponents.MenuItem initially 
> to the menu via Qt.createQmlObject(), then moving it into the desired place 
> before opening the menu.
> 
> Adding the new overload is necessary for binary compatibility. A //BIC 
> comment is added about merging the two methods in the future, as per the BIC 
> page on the community wiki.
> 
> This will be used by the Task Manager applet for dynamically adding actions 
> for recent docs and jump list actions to a task context menu.
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/plasmacomponents/qmenu.h baee963 
>   src/declarativeimports/plasmacomponents/qmenu.cpp d84f481 
> 
> Diff: https://git.reviewboard.kde.org/r/127645/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Eike Hein
> 
>

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

Re: Review Request 127575: Plasma 5.7 "Skylight" Wallpaper

2016-04-13 Thread Ken Vermette


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

(Updated April 13, 2016, 3:51 p.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma.


Changes
---

Submitted with commit f002e5c464863c68307e8c9f8590f6ffaa6d3188 by Ken Vermette 
to branch master.


Repository: breeze


Description
---

New wallpaper for Plasma 5.7

Similar to the 5.6 wallpaper, but using perspective and reflections. Source and 
Splash also attached.


Diffs
-

  wallpapers/Next/contents/images/1024x768.png 60e1205 
  wallpapers/Next/contents/images/1280x1024.png 36a9130 
  wallpapers/Next/contents/images/1280x800.png c33e594 
  wallpapers/Next/contents/images/1440x900.png 2c75b54 
  wallpapers/Next/contents/images/1600x1200.png 5ddaf72 
  wallpapers/Next/contents/images/1638x1024.png a3c7492 
  wallpapers/Next/contents/images/1680x1050.png eddc47e 
  wallpapers/Next/contents/images/1920x1080.png ab6d950 
  wallpapers/Next/contents/images/2560x1440.png 5c78e9d 
  wallpapers/Next/contents/images/2560x1600.png eeb08a1 
  wallpapers/Next/contents/images/3200x1800.png 7340567 
  wallpapers/Next/contents/images/3200x2000.png fd1a62c 
  wallpapers/Next/contents/screenshot.png a6d2b7b 

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


Testing
---


File Attachments


splash.png
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/04/05/450ecd4d-8bbe-48fe-b22a-578ab1968089__splash.png
desktopWallpaper-skylight-1.0-kvermette.png
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/04/05/41f45619-7a37-45dc-a374-27980227414c__2560x1600.png
desktopWallpaper-skylight-1.0-kvermette.svg
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/04/05/b19f3502-0204-44f8-a742-f79ff9701f41__desktopWallpaper-skylight-1.0-kvermette.svg
desktopWallpaper-skylight-1.1-kvermette.svg
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/04/05/4e52288a-6a3c-4af3-a764-66cb9b0538af__desktopWallpaper-skylight-1.1-kvermette.svg
desktopWallpaper-skylight-1.1-kvermette.png
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/04/05/3723026c-f28a-487f-89b4-8e354f4c2715__desktopWallpaper-skylight-1.1-kvermette.png


Thanks,

Ken Vermette

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

[Powerdevil] [Bug 357288] Setting "Screen Energy Saving" in "Energy Saving" config has no effect

2016-04-13 Thread Jake Cobb via KDE Bugzilla

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

Jake Cobb  changed:

   What|Removed |Added

 CC||jake.c...@gmail.com

--- Comment #2 from Jake Cobb  ---
I have this same problem running KDE 5.15.0 (on Ubuntu 15.10) on iMac hardware.
 If I disable screen locking (under System Settings > Desktop Behavior > Screen
Locking), then the monitor will power off as expected with my Screen Energy
Saving setting.  Just having screen locking enabled seems to prevent the power
off from working, e.g. if I tell it to switch off after 1 min and screen
locking is set after 5 minutes, nothing will happen after 1 minute, so it
doesn't seem to be the screen locker re-enabling the monitor.

-- 
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 127640: Update desktopthemedetails docbook to 5.6

2016-04-13 Thread Yuri Chornoivan


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


Ship it!




Ship It!

- Yuri Chornoivan


On Квітень 12, 2016, 6:56 після полудня, Burkhard Lück wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127640/
> ---
> 
> (Updated Квітень 12, 2016, 6:56 після полудня)
> 
> 
> Review request for Documentation and Plasma.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> Remove Info about Details tab and how to configure single components of a 
> theme, feature was removed in 5.6
> 
> Add note to inform users about removed feature to avoid confusion for users, 
> see e.g https://forum.kde.org/viewtopic.php?f=17=132011  
> 
> Add link to techbase page with info about themedetails
> 
> Add recommended tool
> 
> 
> Diffs
> -
> 
>   doc/kcontrol/desktopthemedetails/customizing.png 4ac18a1 
>   doc/kcontrol/desktopthemedetails/index.docbook 2cfa55a 
> 
> Diff: https://git.reviewboard.kde.org/r/127640/diff/
> 
> 
> Testing
> ---
> 
> passes checkXML5
> 
> 
> Thanks,
> 
> Burkhard Lück
> 
>

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

[Differential] [Request, 95 lines] D1403: [autotest] Extend test to verify the code which handles buffer deletions

graesslin created this revision.
graesslin added a reviewer: Plasma.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.

REVISION SUMMARY
  Surface/SubSurface and Shadow handle the case that an attached buffer
  gets destroyed by the client. So far we didn't have this code covered,
  but it's rather important as incorrect reference counting can hit
  asserts.

REPOSITORY
  rKWAYLAND KWayland

BRANCH
  test-destroy-buffer

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

AFFECTED FILES
  autotests/client/test_shadow.cpp
  autotests/client/test_wayland_subsurface.cpp
  autotests/client/test_wayland_surface.cpp

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, Plasma
Cc: plasma-devel, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Updated, 115 lines] D1402: add X11Integration for xcb qpa workarounds

2016-04-13 Thread mart (Marco Martin)

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


  an attempt of autotest

REPOSITORY
  rPLASMAINTEGRATION Integration for Qt applications in Plasma

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D1402?vs=3320=3321

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

AFFECTED FILES
  autotests/CMakeLists.txt
  autotests/kdeplatformtheme_unittest.cpp
  src/platformtheme/CMakeLists.txt
  src/platformtheme/kdeplatformtheme.cpp
  src/platformtheme/kdeplatformtheme.h
  src/platformtheme/x11integration.cpp
  src/platformtheme/x11integration.h

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: mart, graesslin
Cc: plasma-devel, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Requested Changes To] D1402: add X11Integration for xcb qpa workarounds

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


  I highly suggest to add a test case for that to verify that the window has 
the correct NetWm window type.

INLINE COMMENTS
  src/platformtheme/kdeplatformtheme.cpp:52 QX11Info::isPlatformX11()
  src/platformtheme/x11integration.cpp:46 actually I meant doing something 
different: get the X11 window from it and use KWindowSystem to set the proper 
Drag window type.

REPOSITORY
  rPLASMAINTEGRATION Integration for Qt applications in Plasma

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: mart, graesslin
Cc: plasma-devel, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 127643: Right-align labels in IPv4/IPv6 dialogs

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

(Updated April 13, 2016, 1:45 p.m.)

Status
--

This change has been marked as submitted.

Review request for Plasma and Jan Grulich.

Changes
---

Submitted with commit 744a2daa25152fba36d093c0e0a88da496b59650 by Elvis
Angelaccio to branch Plasma/5.6.

Repository: plasma-nm

Description
---

The labels in the IPv4/IPv6 tabs (dialogs) are currently right-aligned. This
violates the following HIG:
https://techbase.kde.org/Projects/Usability/HIG/Alignment#Labels

It is also not consistent with the left-aligned labels in e.g. the Wi-Fi tab.

This patch right-aligns them while keeping the grid layout. An alternative
could be to drop the grid layout and switch to a form layout, which
automatically wuold make the labels left-aligned.

Diffs
-

libs/editor/settings/ui/ipv4.ui de574bd
libs/editor/settings/ui/ipv6.ui 9f08cdc

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

Testing
---

File Attachments

ipv4-before

https://git.reviewboard.kde.org/media/uploaded/files/2016/04/13/62db563c-c510-4431-9b91-251fd2e50e6b__Spectacle.X19386.png
ipv6-before

https://git.reviewboard.kde.org/media/uploaded/files/2016/04/13/82b21b6b-d69a-4acd-9553-b8e75ad234a0__Spectacle.X19393.png
ipv4-after

https://git.reviewboard.kde.org/media/uploaded/files/2016/04/13/b2adf599-e9f1-4c16-996c-d9f430360684__Spectacle.X19407.png
ipv6-after

https://git.reviewboard.kde.org/media/uploaded/files/2016/04/13/4ccfd130-99d0-491e-95cb-144cffe10ae7__Spectacle.X19416.png

Thanks,

Elvis Angelaccio

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

[Differential] [Request, 98 lines] D1402: add X11Integration for xcb qpa workarounds

2016-04-13 Thread mart (Marco Martin)

mart created this revision.
mart added a reviewer: graesslin.
mart set the repository for this revision to rPLASMAINTEGRATION Integration for 
Qt applications in Plasma.
mart added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.

REVISION SUMMARY
  this class will collect some adjustments to the xcb qpa
  make the drag and drop window NOT to be a tooltip

REPOSITORY
  rPLASMAINTEGRATION Integration for Qt applications in Plasma

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

AFFECTED FILES
  autotests/CMakeLists.txt
  src/platformtheme/CMakeLists.txt
  src/platformtheme/kdeplatformtheme.cpp
  src/platformtheme/kdeplatformtheme.h
  src/platformtheme/x11integration.cpp
  src/platformtheme/x11integration.h

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: mart, graesslin
Cc: plasma-devel, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 127586: [calendar] Add a mark to days containing events

2016-04-13 Thread Martin Klapetek



> On April 13, 2016, 10:28 a.m., Marco Martin wrote:
> > what's the status of this?

Working on it.


- Martin


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


On April 6, 2016, 5:53 a.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127586/
> ---
> 
> (Updated April 6, 2016, 5:53 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> Simple triangle at the bottom right corner, see screenshot.
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/calendar/daysmodel.h 8ab232e 
>   src/declarativeimports/calendar/daysmodel.cpp bf99874 
>   src/declarativeimports/calendar/qml/DayDelegate.qml 6353827 
>   src/declarativeimports/calendar/qml/DaysCalendar.qml d4b8fe4 
> 
> Diff: https://git.reviewboard.kde.org/r/127586/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> Screenshot
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/04/06/afefe7ce-7757-4505-9f17-63fca2ec26cb__snapshot109.png
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

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

[Differential] [Closed] D1388: [autotest] Add a test case for QtSurfaceExtensionInterface

This revision was automatically updated to reflect the committed changes.
Closed by commit rKWAYLAND978e053d0069: [autotest] Add a test case for 
QtSurfaceExtensionInterface (authored by graesslin).

REPOSITORY
  rKWAYLAND KWayland

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D1388?vs=3289=3319

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

AFFECTED FILES
  autotests/server/CMakeLists.txt
  autotests/server/surfaceextension_helper.cpp
  autotests/server/test_qt_surface_extension.cpp

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, Plasma, sebas
Cc: sebas, plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Accepted] D1383: Fix crash on repainting an invalid sizes decoration

2016-04-13 Thread Sebastian Kügler

sebas accepted this revision.
sebas added a reviewer: sebas.
sebas added a comment.
This revision is now accepted and ready to land.


  Looks good to me (as far as I understand).

REPOSITORY
  rKWIN KWin

BRANCH
  dont-crash-empty-deco-5.6

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, Plasma, sebas
Cc: sebas, plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Accepted] D1388: [autotest] Add a test case for QtSurfaceExtensionInterface

2016-04-13 Thread Sebastian Kügler

sebas accepted this revision.
sebas added a reviewer: sebas.
sebas added a comment.
This revision is now accepted and ready to land.


  Looks good to me.

REPOSITORY
  rKWAYLAND KWayland

BRANCH
  test-case-qtsurface-extension

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, Plasma, sebas
Cc: sebas, plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Closed] D1400: [autotests] Add test case for FakeInputInterface

This revision was automatically updated to reflect the committed changes.
Closed by commit rKWAYLAND468d9e265bcb: [autotests] Add test case for 
FakeInputInterface (authored by graesslin).

REPOSITORY
  rKWAYLAND KWayland

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D1400?vs=3314=3317

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

AFFECTED FILES
  autotests/client/CMakeLists.txt
  autotests/client/test_fake_input.cpp

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, Plasma, bshah
Cc: plasma-devel, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Closed] D1401: [client] Fix FakeInput::requestPointerAxis

This revision was automatically updated to reflect the committed changes.
Closed by commit rKWAYLAND05ab9e49a2a3: [client] Fix 
FakeInput::requestPointerAxis (authored by graesslin).

REPOSITORY
  rKWAYLAND KWayland

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D1401?vs=3315=3316

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

AFFECTED FILES
  src/client/fakeinput.cpp

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, Plasma, bshah
Cc: plasma-devel, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 127643: Right-align labels in IPv4/IPv6 dialogs



> On April 13, 2016, 10:34 a.m., Kai Uwe Broulik wrote:
> > Shouldn't QFormLayout do that?

Yes, but it requires a more invasive patch (the layout of spacers/buttons is 
messed up if we just change QGridLayout to QFormLayout)


- Elvis


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


On April 13, 2016, 10:18 a.m., Elvis Angelaccio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127643/
> ---
> 
> (Updated April 13, 2016, 10:18 a.m.)
> 
> 
> Review request for Plasma and Jan Grulich.
> 
> 
> Repository: plasma-nm
> 
> 
> Description
> ---
> 
> The labels in the IPv4/IPv6 tabs (dialogs) are currently right-aligned. This 
> violates the following HIG: 
> https://techbase.kde.org/Projects/Usability/HIG/Alignment#Labels
> 
> It is also not consistent with the left-aligned labels in e.g. the Wi-Fi tab.
> 
> This patch right-aligns them while keeping the grid layout. An alternative 
> could be to drop the grid layout and switch to a form layout, which 
> automatically wuold make the labels left-aligned.
> 
> 
> Diffs
> -
> 
>   libs/editor/settings/ui/ipv4.ui de574bd 
>   libs/editor/settings/ui/ipv6.ui 9f08cdc 
> 
> Diff: https://git.reviewboard.kde.org/r/127643/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> ipv4-before
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/04/13/62db563c-c510-4431-9b91-251fd2e50e6b__Spectacle.X19386.png
> ipv6-before
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/04/13/82b21b6b-d69a-4acd-9553-b8e75ad234a0__Spectacle.X19393.png
> ipv4-after
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/04/13/b2adf599-e9f1-4c16-996c-d9f430360684__Spectacle.X19407.png
> ipv6-after
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/04/13/4ccfd130-99d0-491e-95cb-144cffe10ae7__Spectacle.X19416.png
> 
> 
> Thanks,
> 
> Elvis Angelaccio
> 
>

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

Re: Review Request 127643: Right-align labels in IPv4/IPv6 dialogs

2016-04-13 Thread Kai Uwe Broulik


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



Shouldn't QFormLayout do that?

- Kai Uwe Broulik


On April 13, 2016, 10:18 vorm., Elvis Angelaccio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127643/
> ---
> 
> (Updated April 13, 2016, 10:18 vorm.)
> 
> 
> Review request for Plasma and Jan Grulich.
> 
> 
> Repository: plasma-nm
> 
> 
> Description
> ---
> 
> The labels in the IPv4/IPv6 tabs (dialogs) are currently right-aligned. This 
> violates the following HIG: 
> https://techbase.kde.org/Projects/Usability/HIG/Alignment#Labels
> 
> It is also not consistent with the left-aligned labels in e.g. the Wi-Fi tab.
> 
> This patch right-aligns them while keeping the grid layout. An alternative 
> could be to drop the grid layout and switch to a form layout, which 
> automatically wuold make the labels left-aligned.
> 
> 
> Diffs
> -
> 
>   libs/editor/settings/ui/ipv4.ui de574bd 
>   libs/editor/settings/ui/ipv6.ui 9f08cdc 
> 
> Diff: https://git.reviewboard.kde.org/r/127643/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> ipv4-before
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/04/13/62db563c-c510-4431-9b91-251fd2e50e6b__Spectacle.X19386.png
> ipv6-before
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/04/13/82b21b6b-d69a-4acd-9553-b8e75ad234a0__Spectacle.X19393.png
> ipv4-after
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/04/13/b2adf599-e9f1-4c16-996c-d9f430360684__Spectacle.X19407.png
> ipv6-after
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/04/13/4ccfd130-99d0-491e-95cb-144cffe10ae7__Spectacle.X19416.png
> 
> 
> Thanks,
> 
> Elvis Angelaccio
> 
>

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

Re: Review Request 127637: bind highlightedText color in Plasma::Theme


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

(Updated April 13, 2016, 10:29 a.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma.


Changes
---

Submitted with commit 553a9bfe53a48d0d042eb8fe18342137ddbfdca1 by Marco Martin 
to branch master.


Repository: plasma-framework


Description
---

we have a color in the Plasma theme "highlight" that is basically an accent 
color used around.. but one of the uses is to use it as a background, such as 
highlighted text. in that case we don't know what color would be safe for 
contrasting on top of it for things like the highlighted text color (plasma 
style used the background color for that, which is incorrect)


Diffs
-

  autotests/data/plasma/desktoptheme/testtheme/colors PRE-CREATION 
  autotests/data/plasma/desktoptheme/testtheme/metadata.desktop PRE-CREATION 
  autotests/themetest.h b6042c0 
  autotests/themetest.cpp 2165bef 
  src/declarativeimports/core/colorscope.h 38e7cc8 
  src/declarativeimports/core/colorscope.cpp 98ff3ab 
  src/declarativeimports/core/quicktheme.h 79db53c 
  src/declarativeimports/core/quicktheme.cpp 3ef5b88 
  src/declarativeimports/plasmastyle/TextAreaStyle.qml f5be27c 
  src/declarativeimports/plasmastyle/TextFieldStyle.qml 447d7e3 
  src/plasma/private/theme_p.cpp 603cf0a 
  src/plasma/theme.h 3f49719 

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


Testing
---


Thanks,

Marco Martin

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

Re: Review Request 127643: Right-align labels in IPv4/IPv6 dialogs

2016-04-13 Thread Jan Grulich



> On Dub. 13, 2016, 10:24 dop., Jan Grulich wrote:
> > Perfect, looks good. Ship it!!
> 
> Elvis Angelaccio wrote:
> Maybe we could even consider this as a bugfix? And commit it to 5.6 
> branch?

I agree, it doesn't change any string or something like that so you can push it 
to Plasma/5.6 branch too.


- Jan


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


On Dub. 13, 2016, 10:18 dop., Elvis Angelaccio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127643/
> ---
> 
> (Updated Dub. 13, 2016, 10:18 dop.)
> 
> 
> Review request for Plasma and Jan Grulich.
> 
> 
> Repository: plasma-nm
> 
> 
> Description
> ---
> 
> The labels in the IPv4/IPv6 tabs (dialogs) are currently right-aligned. This 
> violates the following HIG: 
> https://techbase.kde.org/Projects/Usability/HIG/Alignment#Labels
> 
> It is also not consistent with the left-aligned labels in e.g. the Wi-Fi tab.
> 
> This patch right-aligns them while keeping the grid layout. An alternative 
> could be to drop the grid layout and switch to a form layout, which 
> automatically wuold make the labels left-aligned.
> 
> 
> Diffs
> -
> 
>   libs/editor/settings/ui/ipv4.ui de574bd 
>   libs/editor/settings/ui/ipv6.ui 9f08cdc 
> 
> Diff: https://git.reviewboard.kde.org/r/127643/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> ipv4-before
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/04/13/62db563c-c510-4431-9b91-251fd2e50e6b__Spectacle.X19386.png
> ipv6-before
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/04/13/82b21b6b-d69a-4acd-9553-b8e75ad234a0__Spectacle.X19393.png
> ipv4-after
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/04/13/b2adf599-e9f1-4c16-996c-d9f430360684__Spectacle.X19407.png
> ipv6-after
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/04/13/4ccfd130-99d0-491e-95cb-144cffe10ae7__Spectacle.X19416.png
> 
> 
> Thanks,
> 
> Elvis Angelaccio
> 
>

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

Re: Review Request 127643: Right-align labels in IPv4/IPv6 dialogs



> On April 13, 2016, 10:24 a.m., Jan Grulich wrote:
> > Perfect, looks good. Ship it!!

Maybe we could even consider this as a bugfix? And commit it to 5.6 branch?


- Elvis


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


On April 13, 2016, 10:18 a.m., Elvis Angelaccio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127643/
> ---
> 
> (Updated April 13, 2016, 10:18 a.m.)
> 
> 
> Review request for Plasma and Jan Grulich.
> 
> 
> Repository: plasma-nm
> 
> 
> Description
> ---
> 
> The labels in the IPv4/IPv6 tabs (dialogs) are currently right-aligned. This 
> violates the following HIG: 
> https://techbase.kde.org/Projects/Usability/HIG/Alignment#Labels
> 
> It is also not consistent with the left-aligned labels in e.g. the Wi-Fi tab.
> 
> This patch right-aligns them while keeping the grid layout. An alternative 
> could be to drop the grid layout and switch to a form layout, which 
> automatically wuold make the labels left-aligned.
> 
> 
> Diffs
> -
> 
>   libs/editor/settings/ui/ipv4.ui de574bd 
>   libs/editor/settings/ui/ipv6.ui 9f08cdc 
> 
> Diff: https://git.reviewboard.kde.org/r/127643/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> ipv4-before
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/04/13/62db563c-c510-4431-9b91-251fd2e50e6b__Spectacle.X19386.png
> ipv6-before
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/04/13/82b21b6b-d69a-4acd-9553-b8e75ad234a0__Spectacle.X19393.png
> ipv4-after
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/04/13/b2adf599-e9f1-4c16-996c-d9f430360684__Spectacle.X19407.png
> ipv6-after
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/04/13/4ccfd130-99d0-491e-95cb-144cffe10ae7__Spectacle.X19416.png
> 
> 
> Thanks,
> 
> Elvis Angelaccio
> 
>

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

Re: Review Request 127643: Right-align labels in IPv4/IPv6 dialogs

2016-04-13 Thread Jan Grulich


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


Ship it!




Perfect, looks good. Ship it!!

- Jan Grulich


On Dub. 13, 2016, 10:18 dop., Elvis Angelaccio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127643/
> ---
> 
> (Updated Dub. 13, 2016, 10:18 dop.)
> 
> 
> Review request for Plasma and Jan Grulich.
> 
> 
> Repository: plasma-nm
> 
> 
> Description
> ---
> 
> The labels in the IPv4/IPv6 tabs (dialogs) are currently right-aligned. This 
> violates the following HIG: 
> https://techbase.kde.org/Projects/Usability/HIG/Alignment#Labels
> 
> It is also not consistent with the left-aligned labels in e.g. the Wi-Fi tab.
> 
> This patch right-aligns them while keeping the grid layout. An alternative 
> could be to drop the grid layout and switch to a form layout, which 
> automatically wuold make the labels left-aligned.
> 
> 
> Diffs
> -
> 
>   libs/editor/settings/ui/ipv4.ui de574bd 
>   libs/editor/settings/ui/ipv6.ui 9f08cdc 
> 
> Diff: https://git.reviewboard.kde.org/r/127643/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> ipv4-before
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/04/13/62db563c-c510-4431-9b91-251fd2e50e6b__Spectacle.X19386.png
> ipv6-before
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/04/13/82b21b6b-d69a-4acd-9553-b8e75ad234a0__Spectacle.X19393.png
> ipv4-after
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/04/13/b2adf599-e9f1-4c16-996c-d9f430360684__Spectacle.X19407.png
> ipv6-after
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/04/13/4ccfd130-99d0-491e-95cb-144cffe10ae7__Spectacle.X19416.png
> 
> 
> Thanks,
> 
> Elvis Angelaccio
> 
>

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

Re: Review Request 127643: Right-align labels in IPv4/IPv6 dialogs


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

(Updated April 13, 2016, 10:18 a.m.)


Review request for Plasma and Jan Grulich.


Changes
---

Drop ampersands and add screenshots.


Repository: plasma-nm


Description
---

The labels in the IPv4/IPv6 tabs (dialogs) are currently right-aligned. This 
violates the following HIG: 
https://techbase.kde.org/Projects/Usability/HIG/Alignment#Labels

It is also not consistent with the left-aligned labels in e.g. the Wi-Fi tab.

This patch right-aligns them while keeping the grid layout. An alternative 
could be to drop the grid layout and switch to a form layout, which 
automatically wuold make the labels left-aligned.


Diffs (updated)
-

  libs/editor/settings/ui/ipv4.ui de574bd 
  libs/editor/settings/ui/ipv6.ui 9f08cdc 

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


Testing
---


File Attachments (updated)


ipv4-before
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/04/13/62db563c-c510-4431-9b91-251fd2e50e6b__Spectacle.X19386.png
ipv6-before
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/04/13/82b21b6b-d69a-4acd-9553-b8e75ad234a0__Spectacle.X19393.png
ipv4-after
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/04/13/b2adf599-e9f1-4c16-996c-d9f430360684__Spectacle.X19407.png
ipv6-after
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/04/13/4ccfd130-99d0-491e-95cb-144cffe10ae7__Spectacle.X19416.png


Thanks,

Elvis Angelaccio

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

[Differential] [Accepted] D1400: [autotests] Add test case for FakeInputInterface

bshah accepted this revision.
bshah added a reviewer: bshah.
This revision is now accepted and ready to land.

REPOSITORY
  rKWAYLAND KWayland

BRANCH
  fake-input-test

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, Plasma, bshah
Cc: plasma-devel, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Accepted] D1401: [client] Fix FakeInput::requestPointerAxis

bshah accepted this revision.
bshah added a reviewer: bshah.
This revision is now accepted and ready to land.

REPOSITORY
  rKWAYLAND KWayland

BRANCH
  fix-fake-input-axis-5.6

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, Plasma, bshah
Cc: plasma-devel, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 127637: bind highlightedText color in Plasma::Theme

2016-04-13 Thread David Edmundson


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


Ship it!




Ship It!

- David Edmundson


On April 13, 2016, 8:47 a.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127637/
> ---
> 
> (Updated April 13, 2016, 8:47 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> we have a color in the Plasma theme "highlight" that is basically an accent 
> color used around.. but one of the uses is to use it as a background, such as 
> highlighted text. in that case we don't know what color would be safe for 
> contrasting on top of it for things like the highlighted text color (plasma 
> style used the background color for that, which is incorrect)
> 
> 
> Diffs
> -
> 
>   autotests/data/plasma/desktoptheme/testtheme/colors PRE-CREATION 
>   autotests/data/plasma/desktoptheme/testtheme/metadata.desktop PRE-CREATION 
>   autotests/themetest.h b6042c0 
>   autotests/themetest.cpp 2165bef 
>   src/declarativeimports/core/colorscope.h 38e7cc8 
>   src/declarativeimports/core/colorscope.cpp 98ff3ab 
>   src/declarativeimports/core/quicktheme.h 79db53c 
>   src/declarativeimports/core/quicktheme.cpp 3ef5b88 
>   src/declarativeimports/plasmastyle/TextAreaStyle.qml f5be27c 
>   src/declarativeimports/plasmastyle/TextFieldStyle.qml 447d7e3 
>   src/plasma/private/theme_p.cpp 603cf0a 
>   src/plasma/theme.h 3f49719 
> 
> Diff: https://git.reviewboard.kde.org/r/127637/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

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

[Differential] [Request, 2 lines] D1401: [client] Fix FakeInput::requestPointerAxis

graesslin created this revision.
graesslin added a reviewer: Plasma.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.

REVISION SUMMARY
  It simulated a button press instead of an axis event.

TEST PLAN
  see https://phabricator.kde.org/D1400

REPOSITORY
  rKWAYLAND KWayland

BRANCH
  fix-fake-input-axis-5.6

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

AFFECTED FILES
  src/client/fakeinput.cpp

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, Plasma
Cc: plasma-devel, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Request, 332 lines] D1400: [autotests] Add test case for FakeInputInterface

graesslin created this revision.
graesslin added a reviewer: Plasma.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.

REPOSITORY
  rKWAYLAND KWayland

BRANCH
  fake-input-test

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

AFFECTED FILES
  autotests/client/CMakeLists.txt
  autotests/client/test_fake_input.cpp

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, Plasma
Cc: plasma-devel, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 127643: Right-align labels in IPv4/IPv6 dialogs

2016-04-13 Thread Jan Grulich


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



Could you please provide screenshot for comparison?


libs/editor/settings/ui/ipv4.ui (line 26)


Be aware that qt-desiner adds  to each string, which is something we 
don't want.



libs/editor/settings/ui/ipv4.ui (line 95)


Same here.



libs/editor/settings/ui/ipv4.ui (line 214)


Same here.



libs/editor/settings/ui/ipv6.ui (line 42)


Same here.



libs/editor/settings/ui/ipv6.ui (line 61)


Same here.



libs/editor/settings/ui/ipv6.ui (line 130)


Same here.


- Jan Grulich


On Dub. 13, 2016, 9:32 dop., Elvis Angelaccio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127643/
> ---
> 
> (Updated Dub. 13, 2016, 9:32 dop.)
> 
> 
> Review request for Plasma and Jan Grulich.
> 
> 
> Repository: plasma-nm
> 
> 
> Description
> ---
> 
> The labels in the IPv4/IPv6 tabs (dialogs) are currently right-aligned. This 
> violates the following HIG: 
> https://techbase.kde.org/Projects/Usability/HIG/Alignment#Labels
> 
> It is also not consistent with the left-aligned labels in e.g. the Wi-Fi tab.
> 
> This patch right-aligns them while keeping the grid layout. An alternative 
> could be to drop the grid layout and switch to a form layout, which 
> automatically wuold make the labels left-aligned.
> 
> 
> Diffs
> -
> 
>   libs/editor/settings/ui/ipv4.ui de574bd 
>   libs/editor/settings/ui/ipv6.ui 9f08cdc 
> 
> Diff: https://git.reviewboard.kde.org/r/127643/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Elvis Angelaccio
> 
>

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

Review Request 127643: Right-align labels in IPv4/IPv6 dialogs


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

Review request for Plasma and Jan Grulich.


Repository: plasma-nm


Description
---

The labels in the IPv4/IPv6 tabs (dialogs) are currently right-aligned. This 
violates the following HIG: 
https://techbase.kde.org/Projects/Usability/HIG/Alignment#Labels

It is also not consistent with the left-aligned labels in e.g. the Wi-Fi tab.

This patch right-aligns them while keeping the grid layout. An alternative 
could be to drop the grid layout and switch to a form layout, which 
automatically wuold make the labels left-aligned.


Diffs
-

  libs/editor/settings/ui/ipv4.ui de574bd 
  libs/editor/settings/ui/ipv6.ui 9f08cdc 

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


Testing
---


Thanks,

Elvis Angelaccio

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

Jenkins-kde-ci: plasma-workspace Plasma-5.6 stable-kf5-qt5 » Linux,gcc - Build # 21 - Failure!

2016-04-13 Thread no-reply


GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/plasma-workspace%20Plasma-5.6%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/21/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Wed, 13 Apr 2016 09:21:03 +
Build duration: 5 min 12 sec

CHANGE SET
Revision ddcf590f968f9b11c392208bf05f4b2072c6e334 by Marco Martin: (close popup 
upon item select)
  change: edit applets/clipboard/contents/ui/ClipboardItemDelegate.qml
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Closed] D1398: [autotest] Add a test case for the shadow interface

This revision was automatically updated to reflect the committed changes.
Closed by commit rKWAYLAND462a5c580d09: [autotest] Add a test case for the 
shadow interface (authored by graesslin).

REPOSITORY
  rKWAYLAND KWayland

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D1398?vs=3311=3313

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

AFFECTED FILES
  autotests/client/CMakeLists.txt
  autotests/client/test_shadow.cpp

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, Plasma, bshah
Cc: plasma-devel, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 127637: bind highlightedText color in Plasma::Theme


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

(Updated April 13, 2016, 8:47 a.m.)


Review request for Plasma.


Changes
---

sample theme has now all different colors in complementary group, to make 
testing more meaningful


Repository: plasma-framework


Description
---

we have a color in the Plasma theme "highlight" that is basically an accent 
color used around.. but one of the uses is to use it as a background, such as 
highlighted text. in that case we don't know what color would be safe for 
contrasting on top of it for things like the highlighted text color (plasma 
style used the background color for that, which is incorrect)


Diffs (updated)
-

  autotests/data/plasma/desktoptheme/testtheme/colors PRE-CREATION 
  autotests/data/plasma/desktoptheme/testtheme/metadata.desktop PRE-CREATION 
  autotests/themetest.h b6042c0 
  autotests/themetest.cpp 2165bef 
  src/declarativeimports/core/colorscope.h 38e7cc8 
  src/declarativeimports/core/colorscope.cpp 98ff3ab 
  src/declarativeimports/core/quicktheme.h 79db53c 
  src/declarativeimports/core/quicktheme.cpp 3ef5b88 
  src/declarativeimports/plasmastyle/TextAreaStyle.qml f5be27c 
  src/declarativeimports/plasmastyle/TextFieldStyle.qml 447d7e3 
  src/plasma/private/theme_p.cpp 603cf0a 
  src/plasma/theme.h 3f49719 

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


Testing
---


Thanks,

Marco Martin

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

Re: Review Request 127637: bind highlightedText color in Plasma::Theme



> On April 12, 2016, 11:38 p.m., David Edmundson wrote:
> > src/plasma/private/theme_p.cpp, line 505
> > 
> >
> > This still has the same bug I pointed out in the first review. 
> > 
> > This should be complementaryhighlightedtextcolor not view

yeah, correction was uncommitted in git, didn't show up in the diff, sorry


- Marco


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


On April 12, 2016, 3:13 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127637/
> ---
> 
> (Updated April 12, 2016, 3:13 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> we have a color in the Plasma theme "highlight" that is basically an accent 
> color used around.. but one of the uses is to use it as a background, such as 
> highlighted text. in that case we don't know what color would be safe for 
> contrasting on top of it for things like the highlighted text color (plasma 
> style used the background color for that, which is incorrect)
> 
> 
> Diffs
> -
> 
>   autotests/data/plasma/desktoptheme/testtheme/colors PRE-CREATION 
>   autotests/data/plasma/desktoptheme/testtheme/metadata.desktop PRE-CREATION 
>   autotests/themetest.h b6042c0 
>   autotests/themetest.cpp 2165bef 
>   src/declarativeimports/core/colorscope.h 38e7cc8 
>   src/declarativeimports/core/colorscope.cpp 98ff3ab 
>   src/declarativeimports/core/quicktheme.h 79db53c 
>   src/declarativeimports/core/quicktheme.cpp 3ef5b88 
>   src/declarativeimports/plasmastyle/TextAreaStyle.qml f5be27c 
>   src/declarativeimports/plasmastyle/TextFieldStyle.qml 447d7e3 
>   src/plasma/private/theme_p.cpp 603cf0a 
>   src/plasma/theme.h 3f49719 
> 
> Diff: https://git.reviewboard.kde.org/r/127637/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

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

[Differential] [Accepted] D1398: [autotest] Add a test case for the shadow interface

bshah accepted this revision.
bshah added a reviewer: bshah.
This revision is now accepted and ready to land.

REPOSITORY
  rKWAYLAND KWayland

BRANCH
  shadow-test

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, Plasma, bshah
Cc: plasma-devel, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Powerdevil] [Bug 361708] New: System stuck in ac-plugged in mode ignoring Power management rules

2016-04-13 Thread Sudhir Khanger via KDE Bugzilla

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

Bug ID: 361708
   Summary: System stuck in ac-plugged in mode ignoring Power
management rules
   Product: Powerdevil
   Version: 5.5.5
  Platform: Fedora RPMs
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: plasma-devel@kde.org
  Reporter: sud...@sudhirkhanger.com

I have noticed it several times that my system won't go into any of the power
states like suspend or hibernate according to the rules set in Power management
settings. The battery icon will be stuck in ac-plugged in state where as on
expanding it, it would show the battery is discharging.

This is very bad because system will eventually shut down and I will lose all
my work.

Reproducible: Sometimes


Actual Results:  
Power management settings are ignored. System doesn't go into suspend or
hibernate as per power management settings. Battery icon shows charging where
as on expanding it shows discharging.


System suspends and hibernates fine via Plasma menu options or via systemctl
but not automatically as per power management settings.

$ upower -d
Device: /org/freedesktop/UPower/devices/line_power_AC
  native-path:  AC
  power supply: yes
  updated:  Wednesday 13 April 2016 09:31:19 AM IST (16286 seconds
ago)
  has history:  no
  has statistics:   no
  line-power
warning-level:   none
online:  yes
icon-name:  'ac-adapter-symbolic'

Device: /org/freedesktop/UPower/devices/battery_BAT0
  native-path:  BAT0
  vendor:   SANYO
  model:42T4763
  serial:   13920
  power supply: yes
  updated:  Wednesday 13 April 2016 02:02:33 PM IST (12 seconds
ago)
  has history:  yes
  has statistics:   yes
  battery
present: yes
rechargeable:yes
state:   discharging
warning-level:   none
energy:  13.07 Wh
energy-empty:0 Wh
energy-full: 27.43 Wh
energy-full-design:  47.52 Wh
energy-rate: 0.415 W
voltage: 11.234 V
time to empty:   31.5 hours
percentage:  47%
capacity:57.7231%
technology:  lithium-ion
icon-name:  'battery-good-symbolic'
  History (charge):
1460536353  47.000  discharging
  History (rate):
1460536353  0.415   discharging

Device: /org/freedesktop/UPower/devices/mouse_0003o046DoC52Fx0002
  native-path: 
/sys/devices/pci:00/:00:1d.0/usb2/2-1/2-1.1/2-1.1:1.1/0003:046D:C52F.0002
  vendor:   Logitech, Inc.
  model:M185
  serial:   03E8C0B4
  power supply: no
  updated:  Wednesday 13 April 2016 02:02:33 PM IST (12 seconds
ago)
  has history:  yes
  has statistics:   no
  mouse
present: no
rechargeable:yes
state:   unknown
warning-level:   none
percentage:  70%
icon-name:  'battery-missing-symbolic'

Device: /org/freedesktop/UPower/devices/DisplayDevice
  power supply: yes
  updated:  Wednesday 13 April 2016 02:02:33 PM IST (12 seconds
ago)
  has history:  no
  has statistics:   no
  battery
present: yes
state:   discharging
warning-level:   none
energy:  13.07 Wh
energy-full: 27.43 Wh
energy-rate: 0.415 W
time to empty:   31.5 hours
percentage:  47%
icon-name:  'battery-good-symbolic'

Daemon:
  daemon-version:  0.99.3
  on-battery:  no
  lid-is-closed:   no
  lid-is-present:  yes
  critical-action: HybridSleep

-- 
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 127586: [calendar] Add a mark to days containing events


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



what's the status of this?

- Marco Martin


On April 6, 2016, 3:53 a.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127586/
> ---
> 
> (Updated April 6, 2016, 3:53 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> Simple triangle at the bottom right corner, see screenshot.
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/calendar/daysmodel.h 8ab232e 
>   src/declarativeimports/calendar/daysmodel.cpp bf99874 
>   src/declarativeimports/calendar/qml/DayDelegate.qml 6353827 
>   src/declarativeimports/calendar/qml/DaysCalendar.qml d4b8fe4 
> 
> Diff: https://git.reviewboard.kde.org/r/127586/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> Screenshot
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/04/06/afefe7ce-7757-4505-9f17-63fca2ec26cb__snapshot109.png
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

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

[Differential] [Request, 1 line] D1399: [shell] Commit surface after removing it's shadow

graesslin created this revision.
graesslin added reviewers: Plasma, mart.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.

REVISION SUMMARY
  Removing the shadow only affects the pending state, we also need to
  explicitly commit the Surface to apply the state change.

REPOSITORY
  rPLASMAWORKSPACE Plasma Workspace

BRANCH
  panelshadow-remove

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

AFFECTED FILES
  shell/panelshadows.cpp

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, Plasma, mart
Cc: plasma-devel, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Request, 260 lines] D1398: [autotest] Add a test case for the shadow interface

graesslin created this revision.
graesslin added a reviewer: Plasma.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.

REVISION SUMMARY
  Basic functionality is covered. Changing of shadow elements not covered,
  there seems to be lacking server API for that - no change signal.

REPOSITORY
  rKWAYLAND KWayland

BRANCH
  shadow-test

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

AFFECTED FILES
  autotests/client/CMakeLists.txt
  autotests/client/test_shadow.cpp

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, Plasma
Cc: plasma-devel, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 127631: [ksmserver] We must be sure that kwin process is ended

2016-04-13 Thread Thomas Lübking



> On April 11, 2016, 5:45 vorm., Martin Gräßlin wrote:
> > > otherwise kwindowsystem::self() is nullptr
> > 
> > how can KWindowSystem::self() be null? And why should that have anything to 
> > do with KWin? KWindowSystem does not depend on a window manager running.
> 
> Thomas Lübking wrote:
> The entire thing sounds as if the problem would be that the session 
> restorage in kwin overrides the placement for restored windows (with the 
> restored position)
> 
> That's however not a bug (at least it's intended) and I've no idea why 
> that's relevant to the weird geometry handling of SNI items (which looks 
> *fr* too complex - the position of remapped windows is usually maintained 
> by QWidget ...)
> 
> Anthony Fieroni wrote:
> I saw the code, it looks like KWindowSystem not depend on Kwin, but Kwin 
> *must* be started *before* use of kwindowsystem. Thomas may right, because 
> setGeometry even not work on sessions restored app.
> When session was finish if start apps with kmail --session session-id 
> everything wors fine.
> 
> Anthony Fieroni wrote:
> Now, after Thomas comment, i even think only widget->show() must works 
> because widget has internal frameGeometry and position.
> 
> Martin Gräßlin wrote:
> > but Kwin must be started before use of kwindowsystem
> 
> no, really there is no reason for that. KWindowSystem doesn't depend on a 
> window manager running.
> 
> Anthony Fieroni wrote:
> Then, correct KWin to kwindowsystem to start working. If there is no bug 
> this will works on all cases -> https://git.reviewboard.kde.org/r/127216/ but 
> it's not.
> 
> Martin Gräßlin wrote:
> I don't know why you have problems, but it's impossible that 
> KWindowSystem::self() returns a nullptr. You can check the code to verify. 
> Something is really broken on your side, but I don't know what. Maybe missing 
> plugins installed?
> 
> Thomas Lübking wrote:
> it's not a hard dependecy on the instace, the sni geometry handling is 
> just plain broken.
> the workaround operates on configure events on the mapped window which 
> will go nowhere if there's no running wm.
> 
> the client needs to handle the no-wm case, ie. configure the window 
> correctly, but to repeat myself: such requirement implies that either sni or 
> qwidget/qwindow is completely fucked up.
> 
> qwindow/qwidget::setGeometry should justwork(tm)
> 
> Anthony Fieroni wrote:
> setGeometry *not* works, i can confirm since i'm test it. Nothing works 
> if Kwin is started *after* usage of kwindowsystem::self().
> Martin yeah nullprt is impossible.
> 
> Martin Gräßlin wrote:
> then this is a bug in Qt's xcb plugin and needs to be fixed there. 
> Setting a geometry without a window manager must be possible.
> 
> Anthony Fieroni wrote:
> Wait a little, the bug is not in xcb. I'm not clear or what. This 
> *happend* only on session restored apps, when kwindowsystem::self() is before 
> kwin statup, only in this case. If run a app after kwin is started *all* 
> works fine setGeometry(), move() - no problems.
> 
> Anthony Fieroni wrote:
> Thomas Lübking wrote:
>  The entire thing sounds as if the problem would be that the session 
> restorage in kwin overrides the placement for restored windows (with the 
> restored position)
>  
> For me, this is best explanation. Adn give you the easiest, no pain, 
> working solution - wait kwin to start completely.
> 
> Martin Gräßlin wrote:
> > Adn give you the easiest, no pain, working solution - wait kwin to 
> start completely.
> 
> I disagree. Working around such problems in the session startup seems 
> wrong. I would say excluse the sni windows from session restore, which can be 
> done from Qt API.
> 
> Thomas Lübking wrote:
> Can we please get few things straight?
> 
> You say that ::setGeometry doesn't work, but 
> https://git.reviewboard.kde.org/r/127216/diff/5#index_header makes use of it 
> (uses the propsed internally saved position and restores it with 
> QWidget::move what's basically a ::setGeometry special case)
> 
> => Does this work (leaving aside session restorage), yes or no?
> 
> Assuming it *does* work (except for session restorage) the claims to 
> require a WM for operative KWindowSystem invocation are gladfully, since 
> you're not using KWindowSystem at all.
> 
> 
> 
> Now onto session restorage:
> ---
> What exactly is the problem here?
> a) the windows are *not* visible when the session restarts. Showing them 
> show them in wrong position
> b) the windows *are* visible when the session restarts, but in wrong 
> position?
> 
> In either case, the session restored geometry and the SNI internal 
> geometry should *not* differ.
> 
> If they do there're two possible problems:
> 1. The window gets stored with the session, but the stored position is 
> wrong (check the

Re: Review Request 127631: [ksmserver] We must be sure that kwin process is ended

2016-04-13 Thread Anthony Fieroni



> On Април 11, 2016, 8:45 преди обяд, Martin Gräßlin wrote:
> > > otherwise kwindowsystem::self() is nullptr
> > 
> > how can KWindowSystem::self() be null? And why should that have anything to 
> > do with KWin? KWindowSystem does not depend on a window manager running.
> 
> Thomas Lübking wrote:
> The entire thing sounds as if the problem would be that the session 
> restorage in kwin overrides the placement for restored windows (with the 
> restored position)
> 
> That's however not a bug (at least it's intended) and I've no idea why 
> that's relevant to the weird geometry handling of SNI items (which looks 
> *fr* too complex - the position of remapped windows is usually maintained 
> by QWidget ...)
> 
> Anthony Fieroni wrote:
> I saw the code, it looks like KWindowSystem not depend on Kwin, but Kwin 
> *must* be started *before* use of kwindowsystem. Thomas may right, because 
> setGeometry even not work on sessions restored app.
> When session was finish if start apps with kmail --session session-id 
> everything wors fine.
> 
> Anthony Fieroni wrote:
> Now, after Thomas comment, i even think only widget->show() must works 
> because widget has internal frameGeometry and position.
> 
> Martin Gräßlin wrote:
> > but Kwin must be started before use of kwindowsystem
> 
> no, really there is no reason for that. KWindowSystem doesn't depend on a 
> window manager running.
> 
> Anthony Fieroni wrote:
> Then, correct KWin to kwindowsystem to start working. If there is no bug 
> this will works on all cases -> https://git.reviewboard.kde.org/r/127216/ but 
> it's not.
> 
> Martin Gräßlin wrote:
> I don't know why you have problems, but it's impossible that 
> KWindowSystem::self() returns a nullptr. You can check the code to verify. 
> Something is really broken on your side, but I don't know what. Maybe missing 
> plugins installed?
> 
> Thomas Lübking wrote:
> it's not a hard dependecy on the instace, the sni geometry handling is 
> just plain broken.
> the workaround operates on configure events on the mapped window which 
> will go nowhere if there's no running wm.
> 
> the client needs to handle the no-wm case, ie. configure the window 
> correctly, but to repeat myself: such requirement implies that either sni or 
> qwidget/qwindow is completely fucked up.
> 
> qwindow/qwidget::setGeometry should justwork(tm)
> 
> Anthony Fieroni wrote:
> setGeometry *not* works, i can confirm since i'm test it. Nothing works 
> if Kwin is started *after* usage of kwindowsystem::self().
> Martin yeah nullprt is impossible.
> 
> Martin Gräßlin wrote:
> then this is a bug in Qt's xcb plugin and needs to be fixed there. 
> Setting a geometry without a window manager must be possible.
> 
> Anthony Fieroni wrote:
> Wait a little, the bug is not in xcb. I'm not clear or what. This 
> *happend* only on session restored apps, when kwindowsystem::self() is before 
> kwin statup, only in this case. If run a app after kwin is started *all* 
> works fine setGeometry(), move() - no problems.
> 
> Anthony Fieroni wrote:
> Thomas Lübking wrote:
>  The entire thing sounds as if the problem would be that the session 
> restorage in kwin overrides the placement for restored windows (with the 
> restored position)
>  
> For me, this is best explanation. Adn give you the easiest, no pain, 
> working solution - wait kwin to start completely.
> 
> Martin Gräßlin wrote:
> > Adn give you the easiest, no pain, working solution - wait kwin to 
> start completely.
> 
> I disagree. Working around such problems in the session startup seems 
> wrong. I would say excluse the sni windows from session restore, which can be 
> done from Qt API.
> 
> Thomas Lübking wrote:
> Can we please get few things straight?
> 
> You say that ::setGeometry doesn't work, but 
> https://git.reviewboard.kde.org/r/127216/diff/5#index_header makes use of it 
> (uses the propsed internally saved position and restores it with 
> QWidget::move what's basically a ::setGeometry special case)
> 
> => Does this work (leaving aside session restorage), yes or no?
> 
> Assuming it *does* work (except for session restorage) the claims to 
> require a WM for operative KWindowSystem invocation are gladfully, since 
> you're not using KWindowSystem at all.
> 
> 
> 
> Now onto session restorage:
> ---
> What exactly is the problem here?
> a) the windows are *not* visible when the session restarts. Showing them 
> show them in wrong position
> b) the windows *are* visible when the session restarts, but in wrong 
> position?
> 
> In either case, the session restored geometry and the SNI internal 
> geometry should *not* differ.
> 
> If they do there're two possible problems:
> 1. The window gets stored with the session, but the stored position is 
> wrong (check

[Powerdevil] [Bug 344456] Plasma 5 desktop does not suspend with only upower, no systemd

2016-04-13 Thread Anton Filimonov via KDE Bugzilla

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

Anton Filimonov  changed:

   What|Removed |Added

 CC||anton.filimo...@gmail.com

--- Comment #38 from Anton Filimonov  ---
Had same problem with suspend in Gentoo with plasma 5.5.5. Localauthority files
mentioned above didn't help. Managed to solve missing suspend issue by adding
polkit rule instead:

polkit.addRule(function(action, subject) {
if (action.id == "org.freedesktop.upower.suspend")
{
return polkit.Result.YES;
}
});

-- 
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 127631: [ksmserver] We must be sure that kwin process is ended

2016-04-13 Thread Thomas Lübking



> On April 11, 2016, 5:45 vorm., Martin Gräßlin wrote:
> > > otherwise kwindowsystem::self() is nullptr
> > 
> > how can KWindowSystem::self() be null? And why should that have anything to 
> > do with KWin? KWindowSystem does not depend on a window manager running.
> 
> Thomas Lübking wrote:
> The entire thing sounds as if the problem would be that the session 
> restorage in kwin overrides the placement for restored windows (with the 
> restored position)
> 
> That's however not a bug (at least it's intended) and I've no idea why 
> that's relevant to the weird geometry handling of SNI items (which looks 
> *fr* too complex - the position of remapped windows is usually maintained 
> by QWidget ...)
> 
> Anthony Fieroni wrote:
> I saw the code, it looks like KWindowSystem not depend on Kwin, but Kwin 
> *must* be started *before* use of kwindowsystem. Thomas may right, because 
> setGeometry even not work on sessions restored app.
> When session was finish if start apps with kmail --session session-id 
> everything wors fine.
> 
> Anthony Fieroni wrote:
> Now, after Thomas comment, i even think only widget->show() must works 
> because widget has internal frameGeometry and position.
> 
> Martin Gräßlin wrote:
> > but Kwin must be started before use of kwindowsystem
> 
> no, really there is no reason for that. KWindowSystem doesn't depend on a 
> window manager running.
> 
> Anthony Fieroni wrote:
> Then, correct KWin to kwindowsystem to start working. If there is no bug 
> this will works on all cases -> https://git.reviewboard.kde.org/r/127216/ but 
> it's not.
> 
> Martin Gräßlin wrote:
> I don't know why you have problems, but it's impossible that 
> KWindowSystem::self() returns a nullptr. You can check the code to verify. 
> Something is really broken on your side, but I don't know what. Maybe missing 
> plugins installed?
> 
> Thomas Lübking wrote:
> it's not a hard dependecy on the instace, the sni geometry handling is 
> just plain broken.
> the workaround operates on configure events on the mapped window which 
> will go nowhere if there's no running wm.
> 
> the client needs to handle the no-wm case, ie. configure the window 
> correctly, but to repeat myself: such requirement implies that either sni or 
> qwidget/qwindow is completely fucked up.
> 
> qwindow/qwidget::setGeometry should justwork(tm)
> 
> Anthony Fieroni wrote:
> setGeometry *not* works, i can confirm since i'm test it. Nothing works 
> if Kwin is started *after* usage of kwindowsystem::self().
> Martin yeah nullprt is impossible.
> 
> Martin Gräßlin wrote:
> then this is a bug in Qt's xcb plugin and needs to be fixed there. 
> Setting a geometry without a window manager must be possible.
> 
> Anthony Fieroni wrote:
> Wait a little, the bug is not in xcb. I'm not clear or what. This 
> *happend* only on session restored apps, when kwindowsystem::self() is before 
> kwin statup, only in this case. If run a app after kwin is started *all* 
> works fine setGeometry(), move() - no problems.
> 
> Anthony Fieroni wrote:
> Thomas Lübking wrote:
>  The entire thing sounds as if the problem would be that the session 
> restorage in kwin overrides the placement for restored windows (with the 
> restored position)
>  
> For me, this is best explanation. Adn give you the easiest, no pain, 
> working solution - wait kwin to start completely.
> 
> Martin Gräßlin wrote:
> > Adn give you the easiest, no pain, working solution - wait kwin to 
> start completely.
> 
> I disagree. Working around such problems in the session startup seems 
> wrong. I would say excluse the sni windows from session restore, which can be 
> done from Qt API.
> 
> Thomas Lübking wrote:
> Can we please get few things straight?
> 
> You say that ::setGeometry doesn't work, but 
> https://git.reviewboard.kde.org/r/127216/diff/5#index_header makes use of it 
> (uses the propsed internally saved position and restores it with 
> QWidget::move what's basically a ::setGeometry special case)
> 
> => Does this work (leaving aside session restorage), yes or no?
> 
> Assuming it *does* work (except for session restorage) the claims to 
> require a WM for operative KWindowSystem invocation are gladfully, since 
> you're not using KWindowSystem at all.
> 
> 
> 
> Now onto session restorage:
> ---
> What exactly is the problem here?
> a) the windows are *not* visible when the session restarts. Showing them 
> show them in wrong position
> b) the windows *are* visible when the session restarts, but in wrong 
> position?
> 
> In either case, the session restored geometry and the SNI internal 
> geometry should *not* differ.
> 
> If they do there're two possible problems:
> 1. The window gets stored with the session, but the stored position is 
> wrong (check the

[Differential] [Closed] D1072: Make sure desktop toolbox has integer and even size

2016-04-13 Thread drosca (David Rosca)

This revision was automatically updated to reflect the committed changes.
Closed by commit rPLASMADESKTOPe2d5d00f0469: Make sure desktop toolbox has 
integer and even size (authored by drosca).

REPOSITORY
  rPLASMADESKTOP Plasma Desktop

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D1072?vs=2565=3310

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

AFFECTED FILES
  toolboxes/desktoptoolbox/contents/ui/ToolBoxButton.qml

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: drosca, Plasma, davidedmundson
Cc: plasma-devel, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Updated] D1397: Depend on Breeze to set the default style name

graesslin added dependencies: D1396: Add PROJECT_VERSION to CMakeLists.txt, 
D1395: Add BREEZE_STYLE_NAME to BreezeConfig.cmake.

REPOSITORY
  rPLASMAINTEGRATION Integration for Qt applications in Plasma

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, Plasma
Cc: plasma-devel, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Request, 21 lines] D1397: Depend on Breeze to set the default style name

graesslin created this revision.
graesslin added a reviewer: Plasma.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.

REVISION SUMMARY
  Instead of hard coding the name to Breeze, we now find Breeze as a
  hard dependency and use the CMake variable of the name to generate
  the name.
  
  This allows us to have a proper dependency set and we can ensure that
  Breeze is installed when using Plasma.

REPOSITORY
  rPLASMAINTEGRATION Integration for Qt applications in Plasma

BRANCH
  depend-on-breeze

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

AFFECTED FILES
  CMakeLists.txt
  autotests/kdeplatformtheme_unittest.cpp
  src/platformtheme/config-platformtheme.h.cmake
  src/platformtheme/khintssettings.cpp

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, Plasma
Cc: plasma-devel, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Commented On] D1366: Add Event Sounds stream to Applications list

2016-04-13 Thread drosca (David Rosca)

drosca added a comment.


  F108465: Screenshot_20160413_083638.png 

REPOSITORY
  rPLASMAPA Plasma Audio Volume Applet

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: drosca, Plasma, Plasma: Design
Cc: broulik, colomar, plasma-devel, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Updated, 237 lines] D1366: Add Event Sounds stream to Applications list

2016-04-13 Thread drosca (David Rosca)

drosca updated this revision to Diff 3308.
drosca added a comment.


  preferences-desktop-notification icon

REPOSITORY
  rPLASMAPA Plasma Audio Volume Applet

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D1366?vs=3300=3308

BRANCH
  event-sounds-stream

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

AFFECTED FILES
  src/CMakeLists.txt
  src/context.cpp
  src/context.h
  src/eventstream.cpp
  src/eventstream.h
  src/kcm/package/contents/ui/StreamListItem.qml
  src/kcm/package/contents/ui/main.qml
  src/maps.h
  src/pulseobject.h
  src/stream.cpp
  src/stream.h

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: drosca, Plasma, Plasma: Design
Cc: broulik, colomar, plasma-devel, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Closed] D1389: [autotest] Add a test case for Idle interface

This revision was automatically updated to reflect the committed changes.
Closed by commit rKWAYLAND1c8a32404c60: [autotest] Add a test case for Idle 
interface (authored by graesslin).

REPOSITORY
  rKWAYLAND KWayland

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D1389?vs=3290=3305

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

AFFECTED FILES
  autotests/client/CMakeLists.txt
  autotests/client/test_idle.cpp

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, Plasma, bshah
Cc: plasma-devel, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Accepted] D1389: [autotest] Add a test case for Idle interface