[Differential] [Accepted] D1534: make the serializer a bit more robust

2016-05-05 Thread Martin Gräßlin 
graesslin accepted this revision.
graesslin added a reviewer: graesslin.
graesslin added a comment.
This revision is now accepted and ready to land.


  Thanks for adding the test case. I appreciate that!

REPOSITORY
  rKSCREEN KScreen

BRANCH
  sebas/fortifyserializer

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

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

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

Re: Review Request 127826: [IconThumbnail] Request for icon, don't let kwindow::icon to decide

2016-05-05 Thread Martin Gräßlin 

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




src/declarativeimports/core/windowthumbnail.cpp (line 245)


showing you the icon look up code from KWin, which is close to perfection 
(doesn't get the 256x256 icon yet):

QIcon icon;
auto readIcon = [this, ](int size, bool scale = true) {
const QPixmap pix = KWindowSystem::icon(window(), size, size, 
scale, KWindowSystem::NETWM | KWindowSystem::WMHints, info);
if (!pix.isNull()) {
icon.addPixmap(pix);
}
};
readIcon(16);
readIcon(32);
readIcon(48, false);
readIcon(64, false);
readIcon(128, false);

The problem here is that we don't specify from where to take the icon (we 
should always try to prefer NETWM) and don't fetch all possible sizes. This is 
rather important because we want neither upscaling, nor downscaling.


- Martin Gräßlin


On May 3, 2016, 8:28 p.m., Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127826/
> ---
> 
> (Updated May 3, 2016, 8:28 p.m.)
> 
> 
> Review request for Plasma, David Edmundson and Martin Gräßlin.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> I'm toking when app is minimized and when hover taskitem in task manager it's 
> drawed a thumnail icon window. So what is the real problem, some apps, many 
> as KDE', not provides their icons in window props and NETWinInfo fails to get 
> them. So in this case we must specified size explicitely to 
> KWindowSystem::icon. But this is not enough because KWindowSystem::icon makes 
> incorrect decision to crop icon to 48x48. Explanation the shots:
> 1. Current code not specified size explicitely, returned icon is 16x16
> 2. New code wants icon 256x256 but KWindowSystem::icon ignore it and 
> returning icon 48x48
> 3. New code in 2 frameworks both, it works.
> So i makes shots with Dragon but many applications are affected, even KDE' 
> akregator, ktimer, kalarm and so on, i don't start to comment other toolkit 
> apps, when we violates KDE'.
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/core/windowthumbnail.cpp 251aaa4 
> 
> Diff: https://git.reviewboard.kde.org/r/127826/diff/
> 
> 
> Testing
> ---
> 
> Depends on https://git.reviewboard.kde.org/r/127809/
> 
> 
> File Attachments
> 
> 
> current plasma-framework and current kwindowsystem
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/05/03/f81bc88b-fe3b-4f00-b2f2-502effe4c245__Screenshot_20160503_202946.png
> new plasma-framework, current kwindowsystem
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/05/03/36d7baa3-e875-420f-b2c2-39c2e5d409b9__Screenshot_20160503_203337.png
> new plasma-framework, new kwindowsystem
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/05/03/857380fe-cdfd-478d-9df2-743f87d4c1ec__Screenshot_20160503_203946.png
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>

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

[Differential] [Commented On] D1538: [libinput] Add a wrapper class Device for a libinput_device

2016-05-05 Thread Martin Gräßlin 
graesslin added a comment.


  In https://phabricator.kde.org/D1538#28537, @sebas wrote:
  
  > Looks good to me.
  >
  > I've tested it on my laptop, and it shows all kind of devices, generally 
the output makes sense. When turning the laptop into tablet mode, nothing seems 
to happen to the keyboard device. It could be that it's just physically blocked 
(there's a neat mechanism which elevates the keyboard backplate so it's flush 
with the keys, keys are at that point not pressable anymore (also nothing shown 
in the debug console) as expected. Trackpoint and touchpad + buttons still work 
(also expected).
  
  
  pity :-(  but somehow I expected that.
  
  > The window size of the debug console is a bit small on my display, it only 
covers about ten lines of the view, and I can't seem to resize the debug 
console window, so it's a bit fiddly.
  
  Yeah, I need to look into making it a proper window. So far KWin had never 
been able to manage it's own windows. Now with Wayland that becomes a 
possibility.

REPOSITORY
  rKWIN KWin

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

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

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

Re: Review Request 127753: [taskmanager] Fixing typos

2016-05-05 Thread Anthony Fieroni 

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

(Updated Май 6, 2016, 6:25 преди обяд)


Review request for Plasma, Kai Uwe Broulik and David Rosca.


Summary (updated)
-

[taskmanager] Fixing typos


Repository: plasma-desktop


Description (updated)
---

^^


Diffs (updated)
-

  applets/taskmanager/package/contents/ui/Task.qml 25ac039 
  applets/taskmanager/package/contents/ui/ToolTipDelegate.qml 383c4a4 

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


Testing (updated)
---


File Attachments


Move mouse pointer fast from here to taskmanager item
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/04/27/382fc7df-83c8-4555-9952-5cc3f4c1a637__Screenshot_20160427_111049.png
toolbutton disappear
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/04/27/4459dbb7-83f6-49f1-b412-bd3a3b514044__Screenshot_20160427_111017.png
Screenshot_20160428_100159.png
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/04/28/84cf7fb4-6b18-40eb-bb8b-8c796375300f__Screenshot_20160428_100159.png


Thanks,

Anthony Fieroni

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

Re: boot logo

2016-05-05 Thread Harald Sitter 
On Thu, May 5, 2016 at 4:14 PM, Marco Martin  wrote:
> On Thursday 05 May 2016 14:51:54 Jonathan Riddell wrote:
>> 1cddf9ba2d38a671cbd2d2536d968aa366547281 switched the plymouth logo
>> from KDE logo to Plasma logo
>>
>> Are there any plans to do the same on the ksplash theme?  It seems
>> strange to have one logo in one screen and another logo in the next
>> screen.
>>
>> What should distro themers do?
>
> shouldn't the plymouth logo always be distro logo and ksplash one be the kde
> logo?

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

Re: Review Request 127842: take highlight and highlightedText from proper color group

2016-05-05 Thread Kai Uwe Broulik 

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



Switching themes no longer properly updates the highlight color, ie. switching 
from Breeze to Honeycomb leaves me with a blue highlight (and brokenness in 
task manager with yellow borders around blue items). Then switching to another 
theme leaves me with the previous highlight, ie. yellow in this case no matter 
the color I chose. Something's broken now.

- Kai Uwe Broulik


On Mai 5, 2016, 10:22 vorm., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127842/
> ---
> 
> (Updated Mai 5, 2016, 10:22 vorm.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> lately the highlight color of plasma became a very washed-out blue, (since it 
> switched to use the global system colors) that was because it actually taken 
> the highlight color (and highlightedText) from the wrong source.
> there is a correct color group in kcolorscheme for that, that is Selection, 
> take those two colors from that (also means highlight and highlightedtext 
> always be the same in all plasma::theme::colorgroups but that's not a problem)
> 
> update test to reflect that
> 
> 
> Diffs
> -
> 
>   autotests/themetest.cpp ce512a4 
>   src/declarativeimports/core/quicktheme.h ac5e121 
>   src/plasma/private/theme_p.h d2246de 
>   src/plasma/private/theme_p.cpp e6d55c3 
> 
> Diff: https://git.reviewboard.kde.org/r/127842/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

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

[kio-extras] [Bug 362709] kio_sftp.cpp:1239]: (style) Suspicious condition

2016-05-05 Thread Christoph Feck via KDE Bugzilla 
https://bugs.kde.org/show_bug.cgi?id=362709

Christoph Feck  changed:

   What|Removed |Added

  Component|general |default
Version|Git |unspecified
Product|kde |kio-extras
   Assignee|unassigned-b...@kde.org |plasma-devel@kde.org

-- 
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: boot logo

2016-05-05 Thread Marco Martin 
On Thursday 05 May 2016 14:51:54 Jonathan Riddell wrote:
> 1cddf9ba2d38a671cbd2d2536d968aa366547281 switched the plymouth logo
> from KDE logo to Plasma logo
> 
> Are there any plans to do the same on the ksplash theme?  It seems
> strange to have one logo in one screen and another logo in the next
> screen.
> 
> What should distro themers do?

shouldn't the plymouth logo always be distro logo and ksplash one be the kde 
logo?

i once proposed to change the ksplash logo (together with start menu icons) to 
the plasma logo (or whatever new plasma logo vdg would come up) but didn't go 
well

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

boot logo

2016-05-05 Thread Jonathan Riddell 
1cddf9ba2d38a671cbd2d2536d968aa366547281 switched the plymouth logo
from KDE logo to Plasma logo

Are there any plans to do the same on the ksplash theme?  It seems
strange to have one logo in one screen and another logo in the next
screen.

What should distro themers do?

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

Re: Review Request 127842: take highlight and highlightedText from proper color group

2016-05-05 Thread Marco Martin 

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

(Updated May 5, 2016, 12:22 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Plasma.


Changes
---

Submitted with commit f0c119696ded3427d577b9aef3d5530a84cfc2f3 by Marco Martin 
to branch master.


Repository: plasma-framework


Description
---

lately the highlight color of plasma became a very washed-out blue, (since it 
switched to use the global system colors) that was because it actually taken 
the highlight color (and highlightedText) from the wrong source.
there is a correct color group in kcolorscheme for that, that is Selection, 
take those two colors from that (also means highlight and highlightedtext 
always be the same in all plasma::theme::colorgroups but that's not a problem)

update test to reflect that


Diffs
-

  autotests/themetest.cpp ce512a4 
  src/declarativeimports/core/quicktheme.h ac5e121 
  src/plasma/private/theme_p.h d2246de 
  src/plasma/private/theme_p.cpp e6d55c3 

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


Testing
---


Thanks,

Marco Martin

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

Re: Review Request 127842: take highlight and highlightedText from proper color group

2016-05-05 Thread Sebastian Kügler 

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


Ship it!




Ship It!

- Sebastian Kügler


On May 5, 2016, 9:54 a.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127842/
> ---
> 
> (Updated May 5, 2016, 9:54 a.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> lately the highlight color of plasma became a very washed-out blue, (since it 
> switched to use the global system colors) that was because it actually taken 
> the highlight color (and highlightedText) from the wrong source.
> there is a correct color group in kcolorscheme for that, that is Selection, 
> take those two colors from that (also means highlight and highlightedtext 
> always be the same in all plasma::theme::colorgroups but that's not a problem)
> 
> update test to reflect that
> 
> 
> Diffs
> -
> 
>   autotests/themetest.cpp ce512a4 
>   src/declarativeimports/core/quicktheme.h ac5e121 
>   src/plasma/private/theme_p.h d2246de 
>   src/plasma/private/theme_p.cpp e6d55c3 
> 
> Diff: https://git.reviewboard.kde.org/r/127842/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

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

Re: Review Request 127842: take highlight and highlightedText from proper color group

2016-05-05 Thread Marco Martin 

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

(Updated May 5, 2016, 9:54 a.m.)


Review request for KDE Frameworks and Plasma.


Changes
---

remove buttonhighlightedtext,viewhighlightedtext etc


as there is only one highlight color, there is also only one highlighted text 
color.

those entries were added after last frameworks release, so can still be removed


Repository: plasma-framework


Description
---

lately the highlight color of plasma became a very washed-out blue, (since it 
switched to use the global system colors) that was because it actually taken 
the highlight color (and highlightedText) from the wrong source.
there is a correct color group in kcolorscheme for that, that is Selection, 
take those two colors from that (also means highlight and highlightedtext 
always be the same in all plasma::theme::colorgroups but that's not a problem)

update test to reflect that


Diffs (updated)
-

  autotests/themetest.cpp ce512a4 
  src/declarativeimports/core/quicktheme.h ac5e121 
  src/plasma/private/theme_p.h d2246de 
  src/plasma/private/theme_p.cpp e6d55c3 

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


Testing
---


Thanks,

Marco Martin

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

Review Request 127842: take highlight and highlightedText from proper color group

2016-05-05 Thread Marco Martin 

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

Review request for KDE Frameworks and Plasma.


Repository: plasma-framework


Description
---

lately the highlight color of plasma became a very washed-out blue, (since it 
switched to use the global system colors) that was because it actually taken 
the highlight color (and highlightedText) from the wrong source.
there is a correct color group in kcolorscheme for that, that is Selection, 
take those two colors from that (also means highlight and highlightedtext 
always be the same in all plasma::theme::colorgroups but that's not a problem)

update test to reflect that


Diffs
-

  autotests/themetest.cpp ce512a4 
  src/plasma/private/theme_p.h d2246de 
  src/plasma/private/theme_p.cpp e6d55c3 

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


Testing
---


Thanks,

Marco Martin

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

Jenkins-kde-ci: plasma-workspace master kf5-qt5 » Linux,gcc - Build # 73 - Still Unstable!

2016-05-05 Thread no-reply 

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/plasma-workspace%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/73/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 05 May 2016 09:07:32 +
Build duration: 17 min

CHANGE SET
Revision 97322fa45118c9ad4670a55288f1bd754ad15caa by ivan.cukic: (Weather IONS: 
Commented out an unused member variable)
  change: edit dataengines/weather/ions/noaa/ion_noaa.h


JUNIT RESULTS

Name: (root) Failed: 2 test(s), Passed: 6 test(s), Skipped: 0 test(s), Total: 8 
test(s)Failed: TestSuite.org.kde.plasma.analogclock-testFailed: 
TestSuite.org.kde.plasma.kickoff-test

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 9/9 (100%)FILES 43/49 (88%)CLASSES 43/49 (88%)LINE 1683/2124 
(79%)CONDITIONAL 1209/2103 (57%)

By packages
  
drkonqi.parser
FILES 6/10 (60%)CLASSES 6/10 (60%)LINE 303/423 (72%)CONDITIONAL 
478/616 (78%)
drkonqi.tests.backtraceparsertest
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 74/74 (100%)CONDITIONAL 
33/50 (66%)
kioslave.desktop
FILES 2/3 (67%)CLASSES 2/3 (67%)LINE 112/167 (67%)CONDITIONAL 
37/92 (40%)
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/210 (52%)
klipper.autotests
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 630/693 (91%)CONDITIONAL 
377/820 (46%)
runners.bookmarks
FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 89/159 (56%)CONDITIONAL 
34/96 (35%)
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/62 (50%)___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Feedback on xdg-shell v5

2016-05-05 Thread Mike Blumenkrantz 
On Fri, Apr 29, 2016 at 4:38 AM Martin Graesslin  wrote:

> On Thursday, April 28, 2016 5:36:58 PM CEST Jonas Ådahl wrote:
> > On Thu, Apr 28, 2016 at 10:36:14AM +0200, Martin Graesslin wrote:
> > > Hi Wayland and Plasma,
> > >
> > > I finished the implementation of xdg-shell in KWayland [1] and KWin
> [2].
> > > Overall it was more straight forward than I would have expected.
> > > Especially
> > > the changes to KWin were surprisingly minor (with one huge exception).
> > >
> > > Now some questions/remarks:
> > > * What's a server supposed to do in use_unstable_version?
> >
> > If a client requests the wrong version, the compositor should send an
> > error, effectively disconnecting the client.
> >
> > Note that this request is gone in v6 and is replaced by the same
> > unstable-protocol-version semantics used in wayland-protocols.
>
> Ok, that's what I though it is. I was just very unsure as killing the
> client
> is nothing I would consider "negotiate version" :-P
>
> >
> > > * Why is the ping on the shell and not on the surface? I would have
> > > expected to ping the surface. At least that's how I would want to do it
> > > from KWin.
> > Because you don't ping a surface, you ping the client. It's the client
> > that may be inresponsive, and if the client is in responsive, it's safe
> > to assume all its surfaces are as well.
>
> Sorry, but I doubt this will work in practice. I have experienced many
> freezes
> with QtWayland applications and in all cases it would respond to the ping.
> Consider:
> * Thread 1: dead-locked waiting for a frame callback
> * Thread 2: Wayland connection getting ping, thread alive, will send pong
>
> I fear that the concept of pinging clients doesn't work in a world where
> connections are in a thread.
>
> Anyway if it's about whether the client is responsive, I suggest to make
> it a
> dedicated protocol. It's not really something which belongs to xdg-shell,
> it's
> a more general concept.
>

I disagree that ping should be outside xdg-shell. The spec for this is
perfectly functional and has been successfully implemented by a number of
compositors/toolkits; claiming that you doubt its practicality based on
your choice to add complexity by using threads (and the bugs that you've
described in your implementation) is not a strong argument towards proving
that ping is not able to be successfully implemented.


>
> >
> > > * Would it be possible to split the states and geometry? I find it
> weird
> > > that I have to send a configure request with a size of 0/0 when
> informing
> > > a surface that it's active.
> >
> > Possible - yes, worth it? I don't know. It's clearly specified that
> > 0 means "let the client come up with it". If you think there is a clear
> > benefit, you're welcome to send a patch targeting v6.
>
> Yes, I think it might be worth it. I don't want that the client starts to
> think it can pick a different size when it becomes active.
>

Compositors can continue to send sizes for all configure events. There is
nothing in the spec which prohibits this behavior, it only says that sizes
may be omitted.


>
> >
> > > The biggest problem for me is the request set_window_geometry. I think
> I
> > > mentioned it already before on the wayland list. Basically I have no
> idea
> > > how to implement that in KWin. We have only one geometry for a window
> and
> > > that's mapped to the size of the surface/x11 pixmap. This geometry is
> > > used all over the place, for positioning, for resizing and for
> rendering.
> > > I cannot add support for this without either breaking code or having to
> > > introduce a new internal API. That's lots of work with high potential
> for
> > > breakage :-(
> > >
> > > From the description it seems to be only relevant for shadows. Could we
> > > make shadows an optional part in xdg-shell? That the server can
> announce
> > > that it supports shadows in the surface?
> >
> > It's not only about shadow. Let me explain a scenario where a window
> > geometry is needed, even when there is a mode where no shadow is drawn
> > by the client.
> >
> > Consider we have the following window:
> >
> >
> > +---+
> >
> > |   A window  X |
> >
> > +---+
> >
> > | /\|
> > |
> > |/  \   |
> > |
> > |   /\  |
> > |
> > |  /  \ |
> > |
> > | /\|
> >
> > +---+
> >
> > It can be split into two logical rectangles/areas: the window title, and
> > the main content. This window may be consisting of two separate
> > non-overlapping surfaces, for example one GLES surface, and one SHM
> > surface. Only one of these surfaces will be the "window", while the
> > other

[Differential] [Accepted] D1487: Don't depend on operation mode in WindowPixmap

2016-05-05 Thread Sebastian Kügler 
sebas accepted this revision.
sebas added a reviewer: sebas.
sebas added a comment.


  Looks sensible.

REPOSITORY
  rKWIN KWin

BRANCH
  window-pixmap-improve-checks

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

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

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

Re: Feedback on xdg-shell v5

2016-05-05 Thread Daniel Stone 
Hi,

On 29 April 2016 at 10:37, Pekka Paalanen  wrote:
> On Fri, 29 Apr 2016 15:31:28 +0800
> Jonas Ådahl  wrote:
>> On Thu, Apr 28, 2016 at 02:08:07PM +0300, Pekka Paalanen wrote:
>> > On Thu, 28 Apr 2016 17:36:58 +0800
>> > Jonas Ådahl  wrote:
>> > > Because you don't ping a surface, you ping the client. It's the client
>> > > that may be inresponsive, and if the client is in responsive, it's safe
>> > > to assume all its surfaces are as well.
>> >
>> > I was going to plain agree and say, that all events to a client come
>> > through the same connection (wl_display), and it does not make sense to
>> > have a series of ping events on different objects when they could just
>> > be collapsed into one equivalent event.
>> >
>> > But then I thought about multiple client-side event queues. If a client
>> > has multiple queues, and windows on different queues, it could be
>> > possible that only some queues get stuck while others are serviced.
>> > With per-surface pings, the compositor should then "shade out" only the
>> > windows where the queue is actually stuck.
>> >
>> > Would it be worth it?
>>
>> I doubt it. What would you do? It's not like you can disconnect half of
>> a client.
>
> Wasn't it more about marking unresponsive surfaces and providing UI
> aids for dealing with them, e.g. moving the window out of the way?
>
> If you hover over the "kill this app" option, the compositor could e.g.
> color all the surfaces that would go, not just the ones unresponsive.

What does 'kill this app' do, if not zap the wl_client? How do you
selectively kill surfaces, or client-side event queues?

There is the argument that one part of the app is active and the other
is dead, but I don't think it's possibly to usefully separate those
out, and also surely you can build an intra-client ping setup as well,
so deadlocked threads result in no pong.

>> > Huh, I always wondered what practical use shadows might have apart
>> > from visual appearance. I can also see how using shadows for any user
>> > interaction while they are outside of the defined window geometry is
>> > going to fail.
>>
>> Why would it fail? It has worked perfectly fine so far. With SSD, this
>> is how things are done as well on X11 - part of the shadow around the
>> window will be available for triggering window resizing. Think of the
>> shadow as part of the window border, instead of just shadow.
>
> Is the shadow a part of window decorations but outside of the
> window geometry?
>
> When you then snap another window beside the first one, you'd snap
> based on the window geometry, right? Then you lose the shadow region of
> the window that happens to be below. The shadow of the window on top
> will extend into and clobber the window below. Or would snap leave a
> shadowy region between the windows? Or do you use window geometry to
> cull the shadow of both windows, in which case you lose it from both on
> the touching egdes?
>
> But yeah, I have no idea how that works. I've never had nor wished for
> shadows, so I can't really understand the big deal about them. I'm
> happy having just nice decorations which are accounted into the window
> geometry.

The shadows are decoration.

>> > > I'd much rather see a solid default which does things "the Wayland way"
>> > > (as described above) that will work reasonably well in a minimalistic
>> > > default weston reference shell, and doesn't imply that the compositor
>> > > should go into effect drawing territory, and I don't think the hybrid
>> > > solution is this.
>> >
>> > I'm not sure there is a "the Wayland way" really for shadows. We did
>> > start with clients just drawing their own shadow as part of the
>> > surface. I assumed that was only because it was very easy to do for a
>> > little bit of eye-candy. We'd have to ask Kristian if there was more
>> > though behind it than that.
>>
>> With "the Wayland way" I really only meant that the compositor, when
>> possible, doesn't spend time rendering eye candy and/or user interfaces.
>
> Sure. This brings us to my suggestion of the default by the Wayland
> way: no shadows at all. No implementation is simpler implementation.

Unfortunately the reality, as shipped in quite a few places by
toytoolkit, GTK+ and others, is that clients render shadows. Any
proposal which doesn't take into account the current on-the-ground
reality (that this has been happening for years) doesn't seem too
serious to me.

>> > I would hope you can find a way to extract shadows as a separate part
>> > of the protocol where the compositor and client can agree on who draws
>> > it, if at all. I'm sure you'll have exactly the same issue with window
>> > decorations in general, especially considering if shadows are actually
>> > functional rather than just visual.
>>
>> We do indeed need a way to do these negotiations. But we also need to
>> have a sane, workable fallback as well.

I fall very, very, firmly on the client-side

[Differential] [Accepted] D1486: Only create damage_handle for Toplevel's without a Wayland Surface

2016-05-05 Thread Sebastian Kügler 
sebas accepted this revision.
sebas added a reviewer: sebas.
This revision is now accepted and ready to land.

REPOSITORY
  rKWIN KWin

BRANCH
  damage-handle-only-create-no-surface

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

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

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

[Differential] [Commented On] D1126: Remove Desktop.SystemSettings import

2016-05-05 Thread mart (Marco Martin) 
mart added a comment.


  fine for me, modulo just the >=

REPOSITORY
  rPLASMADESKTOP Plasma Desktop

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

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

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

[Powerdevil] [Bug 358588] backlight not restored properly, after it was reduced on inactivity

2016-05-05 Thread Māris Nartišs via KDE Bugzilla 
https://bugs.kde.org/show_bug.cgi?id=358588

Māris Nartišs  changed:

   What|Removed |Added

 CC||maris@gmail.com

--- Comment #1 from Māris Nartišs  ---
(In reply to Johannes Hirte from comment #0)
> After some time of inactivity, the backlight of my laptop is reduced as
> configured. But it's not restored, when resuming work on the machine. I can
> adjust the backlight by hand, either Fn-Keys or the "battery and brightness"
> systray. As a result, I get more and more backlighthelper processes. After
> one day, I have more than 100 backlighthelper processes on my system:
> 
> ps -e|grep backlighthelper|wc -l
> 112
> 
> I'm running Gentoo with KF5/Plasma packages from git.
> 
> Reproducible: Always

The growing number of backlight helper processes is not directly related. On my
system backlight levels are restored (more or less) but still I observe one new
extra backlight helper process per brightness change.

kde-plasma/powerdevil-5.6.3
ps fax | grep backlight | wc -l
13
uptime
 09:22:48 up  1:24,  9 users,  load average: 0,82, 0,75, 1,00

-- 
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