date:20151215


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

Ship it!


Ship It!

- Martin Gräßlin


On Dec. 16, 2015, 2:38 a.m., Sebastian Kügler wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126380/
> ---
> 
> (Updated Dec. 16, 2015, 2:38 a.m.)
> 
> 
> Review request for Plasma and Martin Gräßlin.
> 
> 
> Repository: kwayland
> 
> 
> Description
> ---
> 
> This patch transports the EDID data base64-encoded over the wire.
> 
> Apparently, we can't just send random QByteArrays as "strings" over, it has 
> to be encoded and decoded. So...
> 
> - base64-encode the data before sending to the client
> - base64-decode it on the client side
> - document the above, fix documentation woes in the xml definition
> - change test accordingly
> 
> The test data used was actually invalid, it's a base64 string of the actual 
> data, so fix the tests (which actually breaks it), and encode on the 
> server-side and decode on the client side.
> 
> I'm not sure if base64 is the best way to go here, suggestions welcome.
> 
> 
> Diffs
> -
> 
>   autotests/client/test_wayland_outputdevice.cpp beefc45 
>   src/client/outputdevice.cpp bfde34f 
>   src/client/protocols/outputdevice.xml e790fdd 
>   src/server/outputdevice_interface.cpp adf65a1 
> 
> Diff: https://git.reviewboard.kde.org/r/126380/diff/
> 
> 
> Testing
> ---
> 
> broke test by decoding the string from base64, fixed code, tests pass again.
> 
> Also, it works in the libkscreen kwayland backend now.
> 
> 
> Thanks,
> 
> Sebastian Kügler
> 
>

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

[Powerdevil] [Bug 337674] kded5 is eating CPU

2015-12-15 Thread via KDE Bugzilla

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

--- Comment #78 from mif...@gmail.com ---
(In reply to Martin Klapetek from comment #75)
> Are you sure this is when the kded5 process is eating the cpu?
Yep today I got this again. I attached screenshoot and new bt.

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

[Powerdevil] [Bug 337674] kded5 is eating CPU

2015-12-15 Thread via KDE Bugzilla

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

--- Comment #77 from mif...@gmail.com ---
Created attachment 96117
  --> https://bugs.kde.org/attachment.cgi?id=96117&action=edit
thread apply all bt

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

[Powerdevil] [Bug 337674] kded5 is eating CPU

2015-12-15 Thread via KDE Bugzilla

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

--- Comment #76 from mif...@gmail.com ---
Created attachment 96116
  --> https://bugs.kde.org/attachment.cgi?id=96116&action=edit
kded5 cpu usage

-- 
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 126367: Support userActivity in WaylandLocker


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

(Updated Dec. 16, 2015, 7:29 a.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma and Bhushan Shah.


Changes
---

Submitted with commit b396581b75bb9533d908f85ca4d3238d3a3a9cf9 by Martin 
Gräßlin to branch master.


Repository: kscreenlocker


Description
---

Listens for timestamp changes on all SeatInterfaces to emit userActivity.
This fixes broken grace time on Wayland.


Diffs
-

  ksldapp.cpp 43062eaab206951f6c8e0a6636510b5d5f8d08fe 
  waylandlocker.h 9cf3ea4f4310465acdf11bfe30e9871971cb 
  waylandlocker.cpp af7abcefc8f949e5ee9e7553490a22f21c568cb6 

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


Testing
---

Run kwin_wayland
waited till screen locks
moved mouse -> lock screen goes away
waited longer till screen locks and some more
moved mouse -> lock screen doesn't go away


Thanks,

Martin Gräßlin

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

Re: Review Request 126364: [server] Add Display::seats() -> QVector


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

(Updated Dec. 16, 2015, 7:07 a.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma, Bhushan Shah and Sebastian Kügler.


Changes
---

Submitted with commit 6d141c52a9b04b032df0b3d5ea9376ab7e01d000 by Martin 
Gräßlin to branch master.


Repository: kwayland


Description
---

Similar to OutputInterfaces we can have multiple SeatInterfaces so
expose a way to get to all SeatInterfaces.


Diffs
-

  autotests/server/test_seat.cpp 75f93fe0d38eca651773632c060a2b2a5faa47eb 
  src/server/display.h 154e0f0b4c00375ca7d7f0a980392877fe743f50 
  src/server/display.cpp 81ea7316e3b77f6db95748339d3dfaa30d33 

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


Testing
---


Thanks,

Martin Gräßlin

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

Re: Review Request 126381: kwayland backend for libkscreen


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

(Updated Dec. 16, 2015, 2:05 a.m.)


Review request for Plasma, Solid, Daniel Vrátil, and Martin Gräßlin.


Changes
---

fix autotests cmake


Repository: libkscreen


Description
---

This adds a kwayland backend to libkscreen.

This backend uses KWayland's OutputManagement protocol for enlisting and
configuring devices.

Enlisting outputs

KScreen's outputs are created from KWayland::Client::OutputDevice objects,
they copy the data into kscreen's Outputs, and update these objects. A list
of outputs is requested from the client Registry object.

Configuring outputs

The backend asks the global OutputManagement interface for an 
OutputConfiguration
object, then sets the changes per outputdevice on this object, and asks the
compositor to apply() this configuration.

For this to work, the compositor should support the Wayland 
org_kde_kwin_outputdevice
and org_kde_kwin_outputmanagement protocols, for example through
KWayland::Server classes OutputDevice, OutputManagmenent and OuputConfiguration.

General working

WaylandBackend creates a global static internal config, available through
WaylandBackend::internalConfig(). WaylandConfig binds to the wl_registry
callbacks and catches org_kde_kwin_outputdevice creation and destruction.
It passes org_kde_kwin_outputdevice creation and removal on to
WB::internalConfig() to handle its internal data representation as 
WaylandOutput.
WaylandOutput binds to org_kde_kwin_outputdevice's callback, and gets notified
of geometry and modes, including changes. WaylandOutput administrates the
internal representation of these objects, and invokes the global notifier,
which then runs the pointers it holds through the updateK* methods in
Wayland{Screen,Output,...}.

KScreen:{Screen,Output,Edid,Mode} objects are created from the internal
representation as requested (usually triggered by the creation of a
KScreen::Config object through KScreen::Config::current()). As with other
backends, the objects which are handed out to the lib's user are expected
to be deleted by the user, the backend only takes ownership of its internal
data representation objects.


Diffs (updated)
-

  CMakeLists.txt efac5ce 
  autotests/CMakeLists.txt 07b7bbc 
  autotests/configs/default.json 3ac3e19 
  autotests/testconfigserializer.cpp 1af3069 
  autotests/testkwaylandbackend.cpp PRE-CREATION 
  autotests/testkwaylandconfig.cpp PRE-CREATION 
  backends/CMakeLists.txt ff5d751 
  backends/kwayland/CMakeLists.txt PRE-CREATION 
  backends/kwayland/README.txt PRE-CREATION 
  backends/kwayland/waylandbackend.h PRE-CREATION 
  backends/kwayland/waylandbackend.cpp PRE-CREATION 
  backends/kwayland/waylandconfig.h PRE-CREATION 
  backends/kwayland/waylandconfig.cpp PRE-CREATION 
  backends/kwayland/waylandoutput.h PRE-CREATION 
  backends/kwayland/waylandoutput.cpp PRE-CREATION 
  backends/kwayland/waylandscreen.h PRE-CREATION 
  backends/kwayland/waylandscreen.cpp PRE-CREATION 
  src/backendmanager.cpp 89ae31e 
  src/config.cpp e8b8a8f 
  src/screen.h 4cd1e82 
  tests/CMakeLists.txt d5e41d5 
  tests/kwayland/CMakeLists.txt PRE-CREATION 
  tests/kwayland/main.cpp PRE-CREATION 
  tests/kwayland/waylandconfigreader.h PRE-CREATION 
  tests/kwayland/waylandconfigreader.cpp PRE-CREATION 
  tests/kwayland/waylandtestserver.h PRE-CREATION 
  tests/kwayland/waylandtestserver.cpp PRE-CREATION 

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


Testing
---

The patch contains a test server, which is used for the autotests.

The test server uses KWayland's server classes and is set up from the json 
config data we use for the other tests. That means that the backends runs 
against a real server to test everything.

I also tested the kscreen UI, which also works as expected.


Thanks,

Sebastian Kügler

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

Review Request 126381: kwayland backend for libkscreen


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

Review request for Plasma, Solid, Daniel Vrátil, and Martin Gräßlin.


Repository: libkscreen


Description
---

This adds a kwayland backend to libkscreen.

This backend uses KWayland's OutputManagement protocol for enlisting and
configuring devices.

Enlisting outputs

KScreen's outputs are created from KWayland::Client::OutputDevice objects,
they copy the data into kscreen's Outputs, and update these objects. A list
of outputs is requested from the client Registry object.

Configuring outputs

The backend asks the global OutputManagement interface for an 
OutputConfiguration
object, then sets the changes per outputdevice on this object, and asks the
compositor to apply() this configuration.

For this to work, the compositor should support the Wayland 
org_kde_kwin_outputdevice
and org_kde_kwin_outputmanagement protocols, for example through
KWayland::Server classes OutputDevice, OutputManagmenent and OuputConfiguration.

General working

WaylandBackend creates a global static internal config, available through
WaylandBackend::internalConfig(). WaylandConfig binds to the wl_registry
callbacks and catches org_kde_kwin_outputdevice creation and destruction.
It passes org_kde_kwin_outputdevice creation and removal on to
WB::internalConfig() to handle its internal data representation as 
WaylandOutput.
WaylandOutput binds to org_kde_kwin_outputdevice's callback, and gets notified
of geometry and modes, including changes. WaylandOutput administrates the
internal representation of these objects, and invokes the global notifier,
which then runs the pointers it holds through the updateK* methods in
Wayland{Screen,Output,...}.

KScreen:{Screen,Output,Edid,Mode} objects are created from the internal
representation as requested (usually triggered by the creation of a
KScreen::Config object through KScreen::Config::current()). As with other
backends, the objects which are handed out to the lib's user are expected
to be deleted by the user, the backend only takes ownership of its internal
data representation objects.


Diffs
-

  CMakeLists.txt efac5ce 
  autotests/CMakeLists.txt 07b7bbc 
  autotests/configs/default.json 3ac3e19 
  autotests/testconfigserializer.cpp 1af3069 
  autotests/testkwaylandbackend.cpp PRE-CREATION 
  autotests/testkwaylandconfig.cpp PRE-CREATION 
  backends/CMakeLists.txt ff5d751 
  backends/kwayland/CMakeLists.txt PRE-CREATION 
  backends/kwayland/README.txt PRE-CREATION 
  backends/kwayland/waylandbackend.h PRE-CREATION 
  backends/kwayland/waylandbackend.cpp PRE-CREATION 
  backends/kwayland/waylandconfig.h PRE-CREATION 
  backends/kwayland/waylandconfig.cpp PRE-CREATION 
  backends/kwayland/waylandoutput.h PRE-CREATION 
  backends/kwayland/waylandoutput.cpp PRE-CREATION 
  backends/kwayland/waylandscreen.h PRE-CREATION 
  backends/kwayland/waylandscreen.cpp PRE-CREATION 
  src/backendmanager.cpp 89ae31e 
  src/config.cpp e8b8a8f 
  src/screen.h 4cd1e82 
  tests/CMakeLists.txt d5e41d5 
  tests/kwayland/CMakeLists.txt PRE-CREATION 
  tests/kwayland/main.cpp PRE-CREATION 
  tests/kwayland/waylandconfigreader.h PRE-CREATION 
  tests/kwayland/waylandconfigreader.cpp PRE-CREATION 
  tests/kwayland/waylandtestserver.h PRE-CREATION 
  tests/kwayland/waylandtestserver.cpp PRE-CREATION 

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


Testing
---

The patch contains a test server, which is used for the autotests.

The test server uses KWayland's server classes and is set up from the json 
config data we use for the other tests. That means that the backends runs 
against a real server to test everything.

I also tested the kscreen UI, which also works as expected.


Thanks,

Sebastian Kügler

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

Review Request 126380: Fix OutputDevice::edid()


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

Review request for Plasma and Martin Gräßlin.


Repository: kwayland


Description
---

This patch transports the EDID data base64-encoded over the wire.

Apparently, we can't just send random QByteArrays as "strings" over, it has to 
be encoded and decoded. So...

- base64-encode the data before sending to the client
- base64-decode it on the client side
- document the above, fix documentation woes in the xml definition
- change test accordingly

The test data used was actually invalid, it's a base64 string of the actual 
data, so fix the tests (which actually breaks it), and encode on the 
server-side and decode on the client side.

I'm not sure if base64 is the best way to go here, suggestions welcome.


Diffs
-

  autotests/client/test_wayland_outputdevice.cpp beefc45 
  src/client/outputdevice.cpp bfde34f 
  src/client/protocols/outputdevice.xml e790fdd 
  src/server/outputdevice_interface.cpp adf65a1 

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


Testing
---

broke test by decoding the string from base64, fixed code, tests pass again.

Also, it works in the libkscreen kwayland backend now.


Thanks,

Sebastian Kügler

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

Re: Review Request 126373: change the taskbar color from blue to gray

2015-12-15 Thread Martin Klapetek


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


This grey background is currently used for *minimized* tasks.

Please let's not introduce more visual regressions.

- Martin Klapetek


On Dec. 16, 2015, 1:06 a.m., andreas kainz wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126373/
> ---
> 
> (Updated Dec. 16, 2015, 1:06 a.m.)
> 
> 
> Review request for Plasma, Marco Martin and Uri Herrera.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> Problem
> ===
> with the new taskbar we look that the look and feel is consistent between 
> plasma and the applications therefore Uri change the selected application 
> taskbar button to a blue background. The problem is that the blue background 
> couldn't be the same blue than e.g. in the dolphin sidebar cause when you 
> select an element in the sidebar the text color change from "black" to white 
> which isn't possible in the system tray and than the contrast isn't that good 
> in the panel for selected application (gray text on blue background). In 
> addition the blue is very visible. see screenshot before.
> 
> Solution
> 
> I like that we use the same color language but when you look at the dolphin 
> toolbar on top selected elements (e.g. preview in the screenshot) are gray so 
> I change the blue color for the selected application to gray and change 
> minimized app to no border.
> 
> what do you think?
> 
> 
> Diffs
> -
> 
>   src/desktoptheme/breeze/widgets/tasks.svgz 086558b 
> 
> Diff: https://git.reviewboard.kde.org/r/126373/diff/
> 
> 
> Testing
> ---
> 
> I will test the new taskbar and hope someone else can test it too before we 
> may ship it.
> 
> 
> File Attachments
> 
> 
> taskbar style old
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/12/15/28f02c74-3489-4e35-a83f-45bd59a1e681__PlasmaThemeTaskbarBefore.png
> taskbar style new
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/12/15/1f9c7570-114d-4192-b2e5-0c713adfaad7__PlasmaThemeTaskbarAfter.png
> new tasks.svgz file move to /usr/share/plasma/desktoptheme/breeze/widgets/
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/12/16/a6faa46d-1f81-4140-824c-983f6bb5671f__tasks.svgz
> 
> 
> Thanks,
> 
> andreas kainz
> 
>

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

Re: notification plasmoid for desktop

2015-12-15 Thread Martin Klapetek

Hey,

On Tue, Dec 15, 2015 at 7:26 PM, kainz.a  wrote:

> Hi Martin,
>
> would it be possible or a good idea to have the notifications in the panel
> and in addition on the desktop. for the desktop the notifications from the
> pop-up window where shown so you can have a good overview of the
> notification history on the desktop too.
>

Possible, sure. Good idea, not entirely sure.

What would be the use case? Why would the user want to
have that on the desktop? What good would it bring?

Cheers
-- 
Martin Klapetek | KDE Developer
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

activity manager plasmoid for desktop

2015-12-15 Thread kainz.a

Hi Ivan,

you make a great sidebar for the activities. you can come to this "sidebar"
via the activity manger or an shortcut. the activity manager is only
available for the panel would it be possible to use it for the desktop too.
so if you move the activity switcher to the desktop you get the activity
overview from the "sidebar".

thanks for your feedback
Andreas Kainz
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

notification plasmoid for desktop

2015-12-15 Thread kainz.a

Hi Martin,

would it be possible or a good idea to have the notifications in the panel
and in addition on the desktop. for the desktop the notifications from the
pop-up window where shown so you can have a good overview of the
notification history on the desktop too.

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

color picker plasmoid for the desktop

2015-12-15 Thread kainz.a

Hi Kai,

as I saw that you are the developer of the color picker plasmoid I have one
question it the plasmoid only available for the panel as icon with pop up
widget?

would be nice to have the plasmoid also available as desktop plasmoid where
you can show the user the pop-up widget.

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

Re: Review Request 126373: change the taskbar color from blue to gray



> On Dec. 16, 2015, 12:07 a.m., Kai Uwe Broulik wrote:
> > While I'm not fond of this constant change of design language, I do like 
> > that the entries now have a concise border around them; the current light 
> > blue makes them somewhat blurry. I like the gray also.

this is more something like bugfixing not add a new design cause it's fun.


- andreas


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


On Dec. 16, 2015, 12:06 a.m., andreas kainz wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126373/
> ---
> 
> (Updated Dec. 16, 2015, 12:06 a.m.)
> 
> 
> Review request for Plasma, Marco Martin and Uri Herrera.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> Problem
> ===
> with the new taskbar we look that the look and feel is consistent between 
> plasma and the applications therefore Uri change the selected application 
> taskbar button to a blue background. The problem is that the blue background 
> couldn't be the same blue than e.g. in the dolphin sidebar cause when you 
> select an element in the sidebar the text color change from "black" to white 
> which isn't possible in the system tray and than the contrast isn't that good 
> in the panel for selected application (gray text on blue background). In 
> addition the blue is very visible. see screenshot before.
> 
> Solution
> 
> I like that we use the same color language but when you look at the dolphin 
> toolbar on top selected elements (e.g. preview in the screenshot) are gray so 
> I change the blue color for the selected application to gray and change 
> minimized app to no border.
> 
> what do you think?
> 
> 
> Diffs
> -
> 
>   src/desktoptheme/breeze/widgets/tasks.svgz 086558b 
> 
> Diff: https://git.reviewboard.kde.org/r/126373/diff/
> 
> 
> Testing
> ---
> 
> I will test the new taskbar and hope someone else can test it too before we 
> may ship it.
> 
> 
> File Attachments
> 
> 
> taskbar style old
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/12/15/28f02c74-3489-4e35-a83f-45bd59a1e681__PlasmaThemeTaskbarBefore.png
> taskbar style new
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/12/15/1f9c7570-114d-4192-b2e5-0c713adfaad7__PlasmaThemeTaskbarAfter.png
> new tasks.svgz file move to /usr/share/plasma/desktoptheme/breeze/widgets/
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/12/16/a6faa46d-1f81-4140-824c-983f6bb5671f__tasks.svgz
> 
> 
> Thanks,
> 
> andreas kainz
> 
>

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

Re: Review Request 126373: change the taskbar color from blue to gray


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


While I'm not fond of this constant change of design language, I do like that 
the entries now have a concise border around them; the current light blue makes 
them somewhat blurry. I like the gray also.

- Kai Uwe Broulik


On Dez. 16, 2015, 12:06 vorm., andreas kainz wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126373/
> ---
> 
> (Updated Dez. 16, 2015, 12:06 vorm.)
> 
> 
> Review request for Plasma, Marco Martin and Uri Herrera.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> Problem
> ===
> with the new taskbar we look that the look and feel is consistent between 
> plasma and the applications therefore Uri change the selected application 
> taskbar button to a blue background. The problem is that the blue background 
> couldn't be the same blue than e.g. in the dolphin sidebar cause when you 
> select an element in the sidebar the text color change from "black" to white 
> which isn't possible in the system tray and than the contrast isn't that good 
> in the panel for selected application (gray text on blue background). In 
> addition the blue is very visible. see screenshot before.
> 
> Solution
> 
> I like that we use the same color language but when you look at the dolphin 
> toolbar on top selected elements (e.g. preview in the screenshot) are gray so 
> I change the blue color for the selected application to gray and change 
> minimized app to no border.
> 
> what do you think?
> 
> 
> Diffs
> -
> 
>   src/desktoptheme/breeze/widgets/tasks.svgz 086558b 
> 
> Diff: https://git.reviewboard.kde.org/r/126373/diff/
> 
> 
> Testing
> ---
> 
> I will test the new taskbar and hope someone else can test it too before we 
> may ship it.
> 
> 
> File Attachments
> 
> 
> taskbar style old
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/12/15/28f02c74-3489-4e35-a83f-45bd59a1e681__PlasmaThemeTaskbarBefore.png
> taskbar style new
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/12/15/1f9c7570-114d-4192-b2e5-0c713adfaad7__PlasmaThemeTaskbarAfter.png
> new tasks.svgz file move to /usr/share/plasma/desktoptheme/breeze/widgets/
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/12/16/a6faa46d-1f81-4140-824c-983f6bb5671f__tasks.svgz
> 
> 
> Thanks,
> 
> andreas kainz
> 
>

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

Re: Review Request 126373: change the taskbar color from blue to gray

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

(Updated Dec. 16, 2015, 12:06 a.m.)

Review request for Plasma, Marco Martin and Uri Herrera.

Repository: plasma-framework

Description
---

Problem
===
with the new taskbar we look that the look and feel is consistent between
plasma and the applications therefore Uri change the selected application
taskbar button to a blue background. The problem is that the blue background
couldn't be the same blue than e.g. in the dolphin sidebar cause when you
select an element in the sidebar the text color change from "black" to white
which isn't possible in the system tray and than the contrast isn't that good
in the panel for selected application (gray text on blue background). In
addition the blue is very visible. see screenshot before.

Solution

I like that we use the same color language but when you look at the dolphin
toolbar on top selected elements (e.g. preview in the screenshot) are gray so I
change the blue color for the selected application to gray and change minimized
app to no border.

what do you think?

Diffs
-

src/desktoptheme/breeze/widgets/tasks.svgz 086558b

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

Testing
---

I will test the new taskbar and hope someone else can test it too before we may
ship it.

File Attachments (updated)

taskbar style old

https://git.reviewboard.kde.org/media/uploaded/files/2015/12/15/28f02c74-3489-4e35-a83f-45bd59a1e681__PlasmaThemeTaskbarBefore.png
taskbar style new

https://git.reviewboard.kde.org/media/uploaded/files/2015/12/15/1f9c7570-114d-4192-b2e5-0c713adfaad7__PlasmaThemeTaskbarAfter.png
new tasks.svgz file move to /usr/share/plasma/desktoptheme/breeze/widgets/

https://git.reviewboard.kde.org/media/uploaded/files/2015/12/16/a6faa46d-1f81-4140-824c-983f6bb5671f__tasks.svgz

Thanks,

andreas kainz

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

Re: Review Request 126373: change the taskbar color from blue to gray

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

(Updated Dec. 15, 2015, 11:52 p.m.)

Review request for Plasma, Marco Martin and Uri Herrera.

Repository: plasma-framework

Description
---

Solution

what do you think?

Diffs
-

src/desktoptheme/breeze/widgets/tasks.svgz 086558b

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

Testing
---

I will test the new taskbar and hope someone else can test it too before we may
ship it.

File Attachments (updated)

taskbar style old

https://git.reviewboard.kde.org/media/uploaded/files/2015/12/15/28f02c74-3489-4e35-a83f-45bd59a1e681__PlasmaThemeTaskbarBefore.png
taskbar style new

https://git.reviewboard.kde.org/media/uploaded/files/2015/12/15/1f9c7570-114d-4192-b2e5-0c713adfaad7__PlasmaThemeTaskbarAfter.png

Thanks,

andreas kainz

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

Re: Review Request 126373: change the taskbar color from blue to gray

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

(Updated Dec. 15, 2015, 11:52 p.m.)

Review request for Plasma, Marco Martin and Uri Herrera.

Repository: plasma-framework

Description
---

Solution

what do you think?

Diffs
-

src/desktoptheme/breeze/widgets/tasks.svgz 086558b

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

Testing
---

I will test the new taskbar and hope someone else can test it too before we may
ship it.

File Attachments (updated)

taskbar style old

https://git.reviewboard.kde.org/media/uploaded/files/2015/12/15/28f02c74-3489-4e35-a83f-45bd59a1e681__PlasmaThemeTaskbarBefore.png

Thanks,

andreas kainz

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

Review Request 126373: change the taskbar color from blue to gray


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

Review request for Plasma, Marco Martin and Uri Herrera.


Repository: plasma-framework


Description
---

Problem
===
with the new taskbar we look that the look and feel is consistent between 
plasma and the applications therefore Uri change the selected application 
taskbar button to a blue background. The problem is that the blue background 
couldn't be the same blue than e.g. in the dolphin sidebar cause when you 
select an element in the sidebar the text color change from "black" to white 
which isn't possible in the system tray and than the contrast isn't that good 
in the panel for selected application (gray text on blue background). In 
addition the blue is very visible. see screenshot before.

Solution

I like that we use the same color language but when you look at the dolphin 
toolbar on top selected elements (e.g. preview in the screenshot) are gray so I 
change the blue color for the selected application to gray and change minimized 
app to no border.

what do you think?


Diffs
-

  src/desktoptheme/breeze/widgets/tasks.svgz 086558b 

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


Testing
---

I will test the new taskbar and hope someone else can test it too before we may 
ship it.


Thanks,

andreas kainz

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

Review Request 126374: [Activity Pager] Implement drag and drop for Task Manager entries


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

Review request for Plasma and Ivan Čukić.


Repository: kdeplasma-addons


Description
---

Just like you can drop windows from the task manager on the virtual desktop 
pager, you shold be able to do the same with the activity pager.

If set, this naturally unsets the "On All Activities" setting but so does 
dragging the miniature windows.

Also enabled preventStealing so Plasma doesn't create an icon widget in 
response to our drop.


Diffs
-

  CMakeLists.txt 5a654b3 
  applets/activitypager/CMakeLists.txt 078f8ef 
  applets/activitypager/package/contents/ui/main.qml 15a63a5 
  applets/activitypager/plugin/activitypager.h 976e5f1 
  applets/activitypager/plugin/activitypager.cpp 4d1a5a6 

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


Testing
---

Works.

Pretty straightforward but as it introduces a new dependency master only.


Thanks,

Kai Uwe Broulik

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

Re: Review Request 126356: change minimum size of clipboard



> On Dec. 15, 2015, 2:29 p.m., Martin Gräßlin wrote:
> > applets/clipboard/contents/ui/clipboard.qml, line 69
> > 
> >
> > this is not the actual size of the systray, but a hardcoded value which 
> > might match (or not) the size of systray.
> > 
> > As the motivation sounds correct to me I suggest to find a way to 
> > actually use the size of systray. Experts around?

it doesn't have to have the same size than in the system tray popup. I only 
want to reduce the minimum height so that the minimum height would be at least 
the height of the popup. it's only a preset value. you don't have to 
investigate to much time. use a number would be ok. and it doesn't matter what 
would be the minimum size the user have to change the plasmoid size by themself 
at the desktop so it is not a predefinition.


- andreas


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


On Dec. 15, 2015, 12:37 p.m., andreas kainz wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126356/
> ---
> 
> (Updated Dec. 15, 2015, 12:37 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> if you use clipboard on the desktop the minimum window height is heigher than 
> you use clipboard from the panel (drop down window). As the user can define 
> the width and height for the desktop plasmoid the minimum allowed height 
> should be at least the same than the drop down window in the panel. so I 
> change the minimumHeig to 16.
> 
> 
> Diffs
> -
> 
>   applets/clipboard/contents/ui/clipboard.qml 97230c1 
> 
> Diff: https://git.reviewboard.kde.org/r/126356/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> old before with 26 min height
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/12/15/cdc4e222-a954-4f92-816f-521f35aab7c7__clipboard-alt_.png
> new after with 16 min height
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/12/15/50773744-a980-4091-8ef2-7eec516cb597__clipboard-new_.png
> 
> 
> Thanks,
> 
> andreas kainz
> 
>

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

Re: Review Request 123098: Don't show notification popup for persistent notifications when applet is expanded


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

(Updated Dez. 15, 2015, 9:53 nachm.)


Status
--

This change has been discarded.


Review request for Plasma and Martin Klapetek.


Repository: plasma-workspace


Description
---

Persistent notifications are stored in the history. When you have currently 
opened the plasmoid, you would see the notification right away, but it is then 
covered by the popup of exactly the same notification. I tend to keep my tray 
opened when copying lots of files and when the job finishes, I get this "odd" 
behavior.


Diffs
-

  applets/notifications/package/contents/ui/Notifications.qml 4312774 

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


Testing
---

- knotificationdbustest with plasmoid closed yields 3+1 popups
- knotificationdbustest with plasmoid opened yields no popups but the history 
fills accordingly
- notify-send results in a popup either way


Thanks,

Kai Uwe Broulik

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

Re: [Plasmoids] Can I write to file from a pure QML plasmoid?

2015-12-15 Thread kdea

On Monday, December 14, 2015 21:54:02 Sebastian Kügler wrote:

> I'm very reluctant to add generic file I/O to our QML API, as that is going
> to make it very hard to secure it later on. We haven't redone the file I/O
> portions for that reason.

Personally I don't see much difference between a standard application running 
in a window and a QML application running in the panel. Why the first one 
should be able to do File I/O and the second one not? Why running in the panel 
is less secure than running in a window?

On the other hand, I don't see any advantage in having to add C++ to do file 
I/O. A plasmoid isn't more secure if I do file I/O with C++ than if I could do 
file I/O with a QML library. I only see disadvantages in the C++ option:

- The developer will have to learn C++.
- The developer will have to learn how to communicate QML with C++.
- The developer will have to compile the plasmoid for each 
distribution/architecture. Or the user will have to download the source code 
and compile it.

> Perhaps you could tell us about your exact use case, maybe we're able to
> suggest a better solution than to offer a generic file I/O API. (Often,
> there are already solutions for a given purpose.)

Well, the plasmoid will be a surprise :-), so I would prefer to keep the 
details secret until I publish it. I can only say that it requires to read and 
write from/to files in disk, it is a core feature.

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

Re: Plasma 5.5.1

2015-12-15 Thread Weng Xuetian

I saw the 5.5.1 tag is on
https://quickgit.kde.org/?p=plasma-workspace.git&a=commitdiff&h=a0578e6e5dbd429366e6a9837af543a4c85b5a75&hp=1390b40b399770e7a67da714c74d172eee1bb433
, but the tarball doesn't have this commit, can you confirm?

On Tue, Dec 15, 2015 at 5:09 AM, Jonathan Riddell  wrote:
> Plasma 5.5.1 is now released 
> https://www.kde.org/announcements/plasma-5.5.1.php
> ___
> release-team mailing list
> release-t...@kde.org
> https://mail.kde.org/mailman/listinfo/release-team
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Evolving Appdash



On 12/15/2015 08:27 PM, Marco Martin wrote:
> if available even just by shortcut, it should strictly be lazy loading as i 
> wouldn't like something expensive that is loaded and then quite hidden (at 
> this point one could put the toolbox entry in). and in this case i would also 
> like to be able to just right click->alternatives it and load another 
> contaiment to have the old style independent-widgets dashboard (in any case, 
> if is in, must be replaceable/removable).

Yeah, I agree it should be lazy loaded.

Depending on whether it's even needed performancewise, it should
probably use an algorithm like:

- Initially, don't load it until first activated
- Pre-load it at session logon when it was loaded at previous logoff
  slash never unmoaded
- Unload it after 96 hours of non-use

That takes care of "I never used it" (-> never loaded), "I tried it
once and didn't like it" (-> unloaded after some time even if someone
never reboots) and "I use it regularly" (preloaded and fast).



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

Re: Evolving Appdash

On Tuesday 15 December 2015, Eike Hein wrote:
> 
> I think elevating the visibility based on touchscreen presence could
> make sense. How do you see this in practice?

edge swiping only in touchscreen, toolbox/context menu entry maybe only on 
touchscreen, hot corner i would say just if explicitly configured (would end 
up calling a dbus show dashboard method i guess)
I would have it not loaded at all and have to "enable dashboard" in a kcm 
somewhere if a touchscreen is not detected but that's buh, debatable.

> In the a-d matrix from the original mail:
> 
> a) Shortcut always available
> b) Toolbox entry conditional on touchscreen
> c) Hot corner action always off by default
> d) Applet never added by default
> 
> Sound OK?
> 

if available even just by shortcut, it should strictly be lazy loading as i 
wouldn't like something expensive that is loaded and then quite hidden (at 
this point one could put the toolbox entry in). and in this case i would also 
like to be able to just right click->alternatives it and load another 
contaiment to have the old style independent-widgets dashboard (in any case, 
if is in, must be replaceable/removable).

> 
> Appdash from edge swipe sounds really cool. Sounds like this would
> be combined with the hot corner KCM?

it should probably be something kwin-driven, as an invisible window to take 
the input is probably too invasive (should ideally take touch events but be 
completely transparent to mouse)

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

Re: Evolving Appdash

On 12/15/2015 08:11 PM, Martin Klapetek wrote:
> I feel like this argument is not holding very well. We already provide
> KRunner
> by default, which I believe falls into the very same category as this. It's
> just another way to do the same thing (launching an app plus much more
> duplicated functionality) that not everybody uses/needs and yet has it
> loaded by default.

It's about the costs involved, which could be:

* Increasing UI complexity (from just clutter to creating uncertainty
  over which way to do something is the 'right way for me')
* Resource usage

In the default desktop KRunner has some costs when you don't use it:

* It's visible via several Run Command actions distributed over the UI)
* It's a permanently running process, not started on demand

For Appdash it would (presumably) be:

* A Toolbox entry (which might not be shown on a non-touchscreen
  device based on notmart's thinking)

But yeah, the evolution of KDE's Run Command dialog into a permanently-
running search-anything launcher UI is indeed a good example of
"different UI for different frame of mind" even in the context of no
form factor transformation.

During the IRC discussion, it was brought up that the Plasma way of
addressing this is broadly to let you swap out shell components for
alternatives. This doesn't address cases where you want the UI change
to be additive (i.e. provide both shell components at the same time),
though.

The only way we have for this right now is adding widgets, which
imply a permanent visual delegate, which is undesirable in case of
Appdash (see the user bug report).

Adding Appdash to the default cabal of components doesn't address
this meta-problem - but even if we come up with a solution for it,
defaults still matter.

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

Re: Review Request 126185: Make the KAppTemplate CMake module global

2015-12-15 Thread Alex Merry



> On Dec. 12, 2015, 3:35 p.m., Alex Merry wrote:
> > kde-modules/KDETemplateGenerator.cmake, line 84
> > 
> >
> > Use ``KDE_INSTALL_KTEMPLATESDIR`` instead of 
> > ``KTEMPLATES_INSTALL_DIR``. You also need to document that this variable 
> > needs to be set before using the command.
> > 
> > My preference would actually be to make it explicit in the signature 
> > that installation will happen, by having the usage be something like
> > 
> > kde_package_app_templates(
> > TEMPLATES
> > foo
> > bar
> > baz
> > INSTALL_DIR
> > "${KDE_INSTALL_KTEMPLATESDIR}"
> > )
> > 
> > My view is that this makes it explicit what will happen when you're 
> > reading the code - it will package the templates and install them. But I'm 
> > not going to force your hand on this if you'd rather not do it that way.
> 
> Marco Martin wrote:
> would it still take ${KDE_INSTALL_KTEMPLATESDIR} as default or would be 
> mandatory to be passed by the caller?

My preference would be to make it mandatory.


> On Dec. 12, 2015, 3:35 p.m., Alex Merry wrote:
> > kde-modules/KDETemplateGenerator.cmake, line 52
> > 
> >
> > Honestly, I'd just use ARG as the prefix - you're in a function, it's 
> > not going to leak anyway. That means you can refer to ARG_TEMPLATES, which 
> > is both shorter and more descriptive.
> > 
> > You should also check for unparsed arguments, and for the TEMPLATES 
> > argument being missing or empty. See, eg, ECMAddAppIcon.cmake for how to do 
> > this.
> 
> Alex Merry wrote:
> Oops, missed one thing here - you need to 
> ``include(CMakeParseArguments)`` earlier in the file.

You still need to do the check for unparsed arguments and for ARG_TEMPLATES not 
being set (ie: the TEMPLATES keyword being missing).


> On Dec. 12, 2015, 3:35 p.m., Alex Merry wrote:
> > kde-modules/KDETemplateGenerator.cmake, line 14
> > 
> >
> > OK, what needs to be in the subdirectory? are template1, template2 etc 
> > the subdriectory names? The packages file name?
> > 
> > The following sentence suggests this command only creates a single 
> > template tarball, but the signature here has multiple arguments.
> > 
> > Also, the command doesn't need to include the word "template" twice. I 
> > suggest kde_add_app_template.
> > 
> > Finally, the signature now includes the TEMPLATES keyword.
> 
> Marco Martin wrote:
> the subdirectories have the uncompressed templates in it
> the subdirectory names will correspond to the final package name.

OK, so this needs to go in the documentation. I would write it as

kde_package_app_templates(TEMPLATES  [ [...]])

TEMPLATES lists subdirectories containing template files; each 
 directory will be packaged into a file named 
``.tar.bz2`` and installed to the appropriate location.

You should also either describe what should go into a template, or point to 
documentation elsewhere that describes this.


- Alex


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


On Dec. 15, 2015, 10:38 a.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126185/
> ---
> 
> (Updated Dec. 15, 2015, 10:38 a.m.)
> 
> 
> Review request for Build System, KDE Frameworks, Plasma, Aleix Pol Gonzalez, 
> and Simon Wächter.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> templates are very useful as teaching tool in order to make
> a minimal application that uses a certain framework.
> templates in the KAppTemplate repository will always get forgotten
> (plus kapptemplate is not really necessary as they work in kdevelop as well)
> An ideal situation would be frameworks having templates in their own repos
> with templates of barebone apps using the main framework features.
> In order to do that, the cmake stuff needed in order to correctly install
> a template needs to be ported to a place avaiable to all frameworks
> 
> 
> Diffs
> -
> 
>   kde-modules/KDEInstallDirs.cmake b7cd34d 
>   kde-modules/KDETemplateGenerator.cmake PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/126185/diff/
> 
> 
> Testing
> ---
> 
> done some templates installed by plasma-framework
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.or

Re: Review Request 126185: Make the KAppTemplate CMake module global

2015-12-15 Thread Alex Merry


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



kde-modules/KDETemplateGenerator.cmake (line 41)


I'd prefer ``kde_package_app_templates`` (and the module to be called 
``KDEPackageAppTemplates.cmake``).


- Alex Merry


On Dec. 15, 2015, 10:38 a.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126185/
> ---
> 
> (Updated Dec. 15, 2015, 10:38 a.m.)
> 
> 
> Review request for Build System, KDE Frameworks, Plasma, Aleix Pol Gonzalez, 
> and Simon Wächter.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> templates are very useful as teaching tool in order to make
> a minimal application that uses a certain framework.
> templates in the KAppTemplate repository will always get forgotten
> (plus kapptemplate is not really necessary as they work in kdevelop as well)
> An ideal situation would be frameworks having templates in their own repos
> with templates of barebone apps using the main framework features.
> In order to do that, the cmake stuff needed in order to correctly install
> a template needs to be ported to a place avaiable to all frameworks
> 
> 
> Diffs
> -
> 
>   kde-modules/KDEInstallDirs.cmake b7cd34d 
>   kde-modules/KDETemplateGenerator.cmake PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/126185/diff/
> 
> 
> Testing
> ---
> 
> done some templates installed by plasma-framework
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

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

Re: Evolving Appdash

On Tuesday 15 December 2015, Martin Klapetek wrote:
> I feel like this argument is not holding very well. We already provide
> KRunner
> by default, which I believe falls into the very same category as this. It's
> just another way to do the same thing (launching an app plus much more
> duplicated functionality) that not everybody uses/needs and yet has it
> loaded by default.

tough note that also partly for this reason, the menus don't have a complete 
krunner functionality but just a couple of plugins enabled

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

Re: Evolving Appdash

2015-12-15 Thread Martin Klapetek

On Tue, Dec 15, 2015 at 1:45 PM, Marco Martin  wrote:

> On Tuesday 15 December 2015, Eike Hein wrote:
> > I'd like to propose moving kdeplasma-addon's Appdash UI out of
> > kdeplasma-addons into plasma-desktop, fleshing it out a little
> > more and making it available in the following ways:
> >
> > a) Global default keyboard shortcut
> > b) Desktop Toolbox entry
> > c) Available as hot corner action
> > d) Available as a now-optional panel widget
>
> I think I still wouldn't like having it always by default for everybody, 2
> ways to do the same thing (launching an app) by default i don't think is a
> good pattern in general

I feel like this argument is not holding very well. We already provide
KRunner
by default, which I believe falls into the very same category as this. It's
just another way to do the same thing (launching an app plus much more
duplicated functionality) that not everybody uses/needs and yet has it
loaded by default.

Cheers
-- 
Martin Klapetek | KDE Developer
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Evolving Appdash

On 12/15/2015 07:45 PM, Marco Martin wrote:
> I think I still wouldn't like having it always by default for everybody, 2 
> ways to do the same thing (launching an app) by default i don't think is a 
> good pattern in general, especially since a fullscreen grid of very distanced 
> icons while looks cool, is not a good interaction model for the mouse (fits 
> law is the relation of target size *and* the distance traveled to rech it, 
> the 
> second part is often forgotten)

Note appdash is also meant as a keyboard-driven UI - type-to-search
is a common way to use it, there's full spatial nav across all grids,
cursor col preservation moving in multi grid views, etc. I agree that
mouse interaction is the weak point of a UI like this though.

> *BUT* I think it may indeed make sense to add it by default when a 
> touchscreen 
> is detected. why in that case suddenly it makes sense to have 2 ways to do 
> the 
> same thing? because you have 2 input methods that work in a very different 
> way, with very different constraints *working at the same time* (giving 
> interaction pattern headaches that almost make me understand why apple is 
> insisting to not give touchscreen to macs :p), and on a touchscreen a 
> fullscreen grid of huge icons becomes instead very practical, unlike when you 
> only have a mouse or a touchpad.

I think elevating the visibility based on touchscreen presence could
make sense. How do you see this in practice?

In the a-d matrix from the original mail:

a) Shortcut always available
b) Toolbox entry conditional on touchscreen
c) Hot corner action always off by default
d) Applet never added by default

Sound OK?

My one concern here though is that we'll get "Why is it in the Tool-
box on my laptop but not on my desktop" from users though, and I can't
think of a good way to provide config for this. (Windows actually has
a "Tablet Mode" toggle in Win10 that changes the UI, but I'd like to
avoid this.)

> I think it's worth a step back and see what's behind this use case, that i 
> think it's actually valid:
> * some parts of our current shell are not much touchscreen friendly
> * on touchscreens smoe interesting things can be done, like gestures or edge 
> swipes, that we aren't really taking advantage of.

I'd like to add to this that we've previously determined that
screen-spanning UIs and touch also go well together - bigger
touch targets, and simplified window management. It's why the
Netbook shell had a screen-spanning SAL UI and maximized app
windows by default. Appdash is a continuation of that insti-
tutional knowledge buildup.

> for hybrid laptops, i think there are 2 very different use cases: when the 
> user flips and "transforms" the laptop, a very different, tablet-y shell 
> should be loaded, this is an ortogonal problem to the one described here 
> tough.

Right, but I tried to address this earlier: The above may be
the end goal, but to pull it off well we need to iterate towards
it and learn along the way. We're having a much better shot at
doing a "tablet shell" (or could find out whether it's a good or
not idea) well after doing more tablet-friendly UI. It's in part
about getting from A to B in the context of a three months release
schedule.

Now, personally: I'm not convinced dramatically changing the shell
would actually be a good idea in practice, even if the state pre-
servation is very good. The reason is that with hybrids now, hot
detach and reattach is something that's starting to be done very
casually and for short periods of time. Conversion used to require
a reboot, but on my current laptop I can detach the screen, hand
it to someone to watch a movie trailer and attach it back. For
these quick actions, changing the UI a lot is a higher cognitive
load than temporarily living with UI compromises. Knowing about
the Dash and being familiar with it pre-detach and knowing how to
get to it once detached fits this brain muscle memory thing pretty
well.

IOW: Tablet shell makes sense on a tablet-first device, desktop
shell makes sense on a desktop-first device, but being able to
open / swipe in / trigger-however a touch shell overlay on the
desktop shell also makes sense. (Once again adding that Appdash
also has happy keyboard and mouse users though.)

My thinking here is that shipping an Enhanced Appdash will make
users happy enough to use it, and then we can build on their feed-
back to see where we need to go further to meet evolving demands.

> In this case, having the possibility of having also a mobile-style launcher 
> or 
> to have gestures like screen edge swipes can be really useful.
> Going even more generic, and looking at this problem, I would like the 
> possibility to have edge swipe (sounds like it may be a nice wayland 
> extension 
> even :p) to make appear ui like side panels or fullscreen stuff, the launcher 
> may be even just one of the possibilities.
> Heck, this could even give back the "separated widgets dashboard" that some 
> users are a

Re: Review Request 126185: Make the KAppTemplate CMake module global

2015-12-15 Thread Alex Merry



> On Dec. 12, 2015, 3:40 p.m., Alex Merry wrote:
> > Ooh, also, please write a unit test. I can help with that if you find the 
> > idea of writing a CMake-based unit test daunting, but you can look in the 
> > tests directory for inspiration.
> 
> Marco Martin wrote:
> I'm not sure what the test should do...
> perhaps having in the repo a tarball and a source template, make it 
> generate and then compare the files?

Yes, that would work. Or you could have a source template, and check the 
installed file can be extracted and check the extracted contents. Don't forget 
to make sure that files you think should be excluded are in fact omitted.


- Alex


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


On Dec. 15, 2015, 10:38 a.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126185/
> ---
> 
> (Updated Dec. 15, 2015, 10:38 a.m.)
> 
> 
> Review request for Build System, KDE Frameworks, Plasma, Aleix Pol Gonzalez, 
> and Simon Wächter.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> templates are very useful as teaching tool in order to make
> a minimal application that uses a certain framework.
> templates in the KAppTemplate repository will always get forgotten
> (plus kapptemplate is not really necessary as they work in kdevelop as well)
> An ideal situation would be frameworks having templates in their own repos
> with templates of barebone apps using the main framework features.
> In order to do that, the cmake stuff needed in order to correctly install
> a template needs to be ported to a place avaiable to all frameworks
> 
> 
> Diffs
> -
> 
>   kde-modules/KDEInstallDirs.cmake b7cd34d 
>   kde-modules/KDETemplateGenerator.cmake PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/126185/diff/
> 
> 
> Testing
> ---
> 
> done some templates installed by plasma-framework
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

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

Re: Evolving Appdash

On Tuesday 15 December 2015, Eike Hein wrote:
> I'd like to propose moving kdeplasma-addon's Appdash UI out of
> kdeplasma-addons into plasma-desktop, fleshing it out a little
> more and making it available in the following ways:
> 
> a) Global default keyboard shortcut
> b) Desktop Toolbox entry
> c) Available as hot corner action
> d) Available as a now-optional panel widget

I think I still wouldn't like having it always by default for everybody, 2 
ways to do the same thing (launching an app) by default i don't think is a 
good pattern in general, especially since a fullscreen grid of very distanced 
icons while looks cool, is not a good interaction model for the mouse (fits 
law is the relation of target size *and* the distance traveled to rech it, the 
second part is often forgotten)

*BUT* I think it may indeed make sense to add it by default when a touchscreen 
is detected. why in that case suddenly it makes sense to have 2 ways to do the 
same thing? because you have 2 input methods that work in a very different 
way, with very different constraints *working at the same time* (giving 
interaction pattern headaches that almost make me understand why apple is 
insisting to not give touchscreen to macs :p), and on a touchscreen a 
fullscreen grid of huge icons becomes instead very practical, unlike when you 
only have a mouse or a touchpad.

> * $user is using a touchscreen laptop or 2-in-1 hybrid in
>   tablet mode. They're using traditional desktop UI elements
>   most of the time (e.g. when getting work done inside classic
>   apps), but some of the time enjoy leaning back and using a
>   more generously spaced, distraction-free UI with bigger
>   touch targets. (Often e.g. as an onboarding experience to
>   a touch-driven UI like PMC/Kodi or a tablet-friendly game.)

I think it's worth a step back and see what's behind this use case, that i 
think it's actually valid:
* some parts of our current shell are not much touchscreen friendly
* on touchscreens smoe interesting things can be done, like gestures or edge 
swipes, that we aren't really taking advantage of.

for hybrid laptops, i think there are 2 very different use cases: when the 
user flips and "transforms" the laptop, a very different, tablet-y shell 
should be loaded, this is an ortogonal problem to the one described here 
tough.

The common use is the laptop is still as a laptop, but with a working 
touchscreen, here the normal use pattern is using just the touchpad ~90% of 
the time, but just occasionally here and there touching the screen to do 
stuff, either because a particular thing is easier with the touch screen or 
just because "feel like doing so".

In this case, having the possibility of having also a mobile-style launcher or 
to have gestures like screen edge swipes can be really useful.
Going even more generic, and looking at this problem, I would like the 
possibility to have edge swipe (sounds like it may be a nice wayland extension 
even :p) to make appear ui like side panels or fullscreen stuff, the launcher 
may be even just one of the possibilities.
Heck, this could even give back the "separated widgets dashboard" that some 
users are asking back, so I could see the possibility of showing a generic 
containment shown with one of such gestures.
(as a side note, Appdash could just become a generic containment.. doesn't 
have to support widgets.. can even be added in the containment api that adding 
widgets is not supported)
This would even give back the use case i've seen used many times in kde4 of 
the search and launch containment used as main desktop containment)

And also for people to implement new things, ideas, alternate UI pieces that 
can fill that space.

> * $user is of the traditional mouse and keyboard variety and
>   enjoys using a small windowed launcher for activities like
>   drilling down to a specific menu category and app, but
>   prefers using a fullscreen UI for search and exploration-
>   like activity.
> 
> These user scenarios have been encountered on the issue tracker
> and in user venues before in various forms. They exist right
> now, but require some compromises from these users like adding
> a panel applet that may be unused. Competitive pressure
> (several products competing with Plasma Desktop now ship default
> UI addressing these needs) adds to it.
> 
> During the IRC meeting there was some concern about diluting the
> overall UI by having "more than one way to do it", however in the
> above user scenarios this appears desired, because:

yeah, as I said, I would prefer to having it enabled only when a touchscreen 
gets detected, because then the 2 ways to do the same thing become very 
justified.
That doesn't mean it shouldn't be possible to just enable with a click by who 
wants it anyways (and anyways I would like, if it gets in, to be able anyways 
to load different things, like "a dashboard with generic widgets", a fancy 
fullscreen activity manager, a folderview, or $newfancythingi

Evolving Appdash


I'd like to propose moving kdeplasma-addon's Appdash UI out of
kdeplasma-addons into plasma-desktop, fleshing it out a little
more and making it available in the following ways:

a) Global default keyboard shortcut
b) Desktop Toolbox entry
c) Available as hot corner action
d) Available as a now-optional panel widget

Fleshing out mainly refers to the addition of basic system
control knobs like networking toggles and display brightness.

Concretely, this would address user wishes to be able to access
Appdash without requiring the presence of a panel widget.

More broadly, the enhanced Appdash would satisfy the following
user scenarios without the need to have two panel widgets or
pick just one UI:

* $user is using a touchscreen laptop or 2-in-1 hybrid in
  tablet mode. They're using traditional desktop UI elements
  most of the time (e.g. when getting work done inside classic
  apps), but some of the time enjoy leaning back and using a
  more generously spaced, distraction-free UI with bigger
  touch targets. (Often e.g. as an onboarding experience to
  a touch-driven UI like PMC/Kodi or a tablet-friendly game.)

* $user is of the traditional mouse and keyboard variety and
  enjoys using a small windowed launcher for activities like
  drilling down to a specific menu category and app, but
  prefers using a fullscreen UI for search and exploration-
  like activity.

These user scenarios have been encountered on the issue tracker
and in user venues before in various forms. They exist right
now, but require some compromises from these users like adding
a panel applet that may be unused. Competitive pressure
(several products competing with Plasma Desktop now ship default
UI addressing these needs) adds to it.

During the IRC meeting there was some concern about diluting the
overall UI by having "more than one way to do it", however in the
above user scenarios this appears desired, because:

* "Doing it" is a very subtle thing. "Start any application" might
  appear to be "it", but in reality the difference between "start
  an application I know about" and "look around the apps I have
  installed to see whether I want to start one" can matter, for
  example, and different UIs support different frame of mind to
  varying degrees.

* Plasma Desktop is positioned as a UI product for multi form
  factor devices which change form factor at runtime due to both
  physical reconfiguration of the device (de- and reattaching
  the screen/keyboard) and user frame of mind (whatever compells
  a user to poke the screen instead of using the trackpad at any
  moment). We've long had goals to support this sort of thing
  well (shell package swapping, form factor awareness in core
  frameworks, etc., are a reflection of this) and this proposal
  is meant as a prong of the same fork: Iterate on the UI we
  make available to hybrid devices to get closer to our goals.

The proposal aims to achieve this by (a) evolving and making
suitable and popular UI we have available in the core desktop
package and (b) keeping it unobtrusive by default (if you don't
use it, you can ignore it).

In terms of implementation, abstracting things so the actual
Appdash implementation implements some sort of generic interface
called by shell code seems fine. Note that the Appdash code is
effectively already in p-d (kdeplasma-addons just carries a
.desktop file for the panel applet). Instanciation should be
retooled to do lazy-loading.

The VDG has offered to join in with some cool mockups to maxi-
mize potential.


As a closing note, since we're dealing in engineering issues
much of the day, we're sometimes very heavily habituated to
react to proposals with a mindset of scanning for "what's wrong
with this". This is an excellent mindset to adopt for code
review, but it's pretty awful for product evolution. A mix of
"what's right about this" or "what motivates this" works much
better.


Cheers,
Eike


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

Re: Review Request 126348: Make it possible to provide the metadata in json



> On Dec. 14, 2015, 9:50 p.m., Sebastian Kügler wrote:
> > src/kpackage/private/packagejobthread.cpp, line 189
> > 
> >
> > Why this change?
> 
> Aleix Pol Gonzalez wrote:
> because currently it's not a text file. I can commit separately if you 
> want.

.desktop and .json are not text files? (Sorry, trying to not be dense here, but 
I don't understand...)


- Sebastian


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


On Dec. 15, 2015, 3:24 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126348/
> ---
> 
> (Updated Dec. 15, 2015, 3:24 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: kpackage
> 
> 
> Description
> ---
> 
> Due to KCoreAddons transition from using desktop files to json files, 
> KPackage ended in a weird state where desktop files were allowed to use 
> desktop files but not json.
> 
> This patch makes sure that manifest.json files are also acceptable.
> 
> 
> Diffs
> -
> 
>   autotests/data/testjsonmetadatapackage/contents/ui/main.qml PRE-CREATION 
>   autotests/data/testjsonmetadatapackage/metadata.json PRE-CREATION 
>   autotests/querytest.cpp 0a2f11a 
>   src/kpackage/package.cpp 8416054 
>   src/kpackage/packageloader.cpp 1e1e382 
>   src/kpackage/private/packagejobthread.cpp 444dacc 
>   src/kpackage/private/packages.cpp 2f6bbcf 
> 
> Diff: https://git.reviewboard.kde.org/r/126348/diff/
> 
> 
> Testing
> ---
> 
> Tests still pass (except for 
> https://build.kde.org/job/kpackage%20master%20stable-kf5-qt5/37/PLATFORM=Linux,compiler=gcc/testReport/,
>  that is not passing in master).
> Adds a test plugin with a json file in it.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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

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

2015-12-15 Thread Pinak Ahuja


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

(Updated Dec. 15, 2015, 3:44 p.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma and Vishesh Handa.


Changes
---

Submitted with commit 93e437c684ed57fefcf2f5821edd52008e60c2a2 by Pinak Ahuja 
to branch master.


Repository: plasma-desktop


Description
---

Also use the new Baloo::IndexerConfig::refresh()


Diffs
-

  kcms/baloo/kcm.cpp 8012a3b 

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


Testing
---


Thanks,

Pinak Ahuja

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

Re: Review Request 126348: Make it possible to provide the metadata in json

2015-12-15 Thread Alex Richardson


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



src/kpackage/package.cpp (line 24)


no longer required, right?



src/kpackage/package.cpp (line 916)


`path.endsWith("/metadata.desktop") || path.endsWith("/metadata.json")`? 
QRegExp seems like overkill here.


- Alex Richardson


On Dec. 15, 2015, 3:24 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126348/
> ---
> 
> (Updated Dec. 15, 2015, 3:24 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: kpackage
> 
> 
> Description
> ---
> 
> Due to KCoreAddons transition from using desktop files to json files, 
> KPackage ended in a weird state where desktop files were allowed to use 
> desktop files but not json.
> 
> This patch makes sure that manifest.json files are also acceptable.
> 
> 
> Diffs
> -
> 
>   autotests/data/testjsonmetadatapackage/contents/ui/main.qml PRE-CREATION 
>   autotests/data/testjsonmetadatapackage/metadata.json PRE-CREATION 
>   autotests/querytest.cpp 0a2f11a 
>   src/kpackage/package.cpp 8416054 
>   src/kpackage/packageloader.cpp 1e1e382 
>   src/kpackage/private/packagejobthread.cpp 444dacc 
>   src/kpackage/private/packages.cpp 2f6bbcf 
> 
> Diff: https://git.reviewboard.kde.org/r/126348/diff/
> 
> 
> Testing
> ---
> 
> Tests still pass (except for 
> https://build.kde.org/job/kpackage%20master%20stable-kf5-qt5/37/PLATFORM=Linux,compiler=gcc/testReport/,
>  that is not passing in master).
> Adds a test plugin with a json file in it.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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

Review Request 126367: Support userActivity in WaylandLocker


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

Review request for Plasma and Bhushan Shah.


Repository: kscreenlocker


Description
---

Listens for timestamp changes on all SeatInterfaces to emit userActivity.
This fixes broken grace time on Wayland.


Diffs
-

  ksldapp.cpp 43062eaab206951f6c8e0a6636510b5d5f8d08fe 
  waylandlocker.h 9cf3ea4f4310465acdf11bfe30e9871971cb 
  waylandlocker.cpp af7abcefc8f949e5ee9e7553490a22f21c568cb6 

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


Testing
---

Run kwin_wayland
waited till screen locks
moved mouse -> lock screen goes away
waited longer till screen locks and some more
moved mouse -> lock screen doesn't go away


Thanks,

Martin Gräßlin

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

Re: Review Request 126367: Support userActivity in WaylandLocker

2015-12-15 Thread Bhushan Shah


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

Ship it!


Ship It!

- Bhushan Shah


On Dec. 15, 2015, 8:49 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126367/
> ---
> 
> (Updated Dec. 15, 2015, 8:49 p.m.)
> 
> 
> Review request for Plasma and Bhushan Shah.
> 
> 
> Repository: kscreenlocker
> 
> 
> Description
> ---
> 
> Listens for timestamp changes on all SeatInterfaces to emit userActivity.
> This fixes broken grace time on Wayland.
> 
> 
> Diffs
> -
> 
>   ksldapp.cpp 43062eaab206951f6c8e0a6636510b5d5f8d08fe 
>   waylandlocker.h 9cf3ea4f4310465acdf11bfe30e9871971cb 
>   waylandlocker.cpp af7abcefc8f949e5ee9e7553490a22f21c568cb6 
> 
> Diff: https://git.reviewboard.kde.org/r/126367/diff/
> 
> 
> Testing
> ---
> 
> Run kwin_wayland
> waited till screen locks
> moved mouse -> lock screen goes away
> waited longer till screen locks and some more
> moved mouse -> lock screen doesn't go away
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

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

Re: Review Request 126348: Make it possible to provide the metadata in json

2015-12-15 Thread Aleix Pol Gonzalez



> On Dec. 14, 2015, 10:50 p.m., Sebastian Kügler wrote:
> > src/kpackage/private/packagejobthread.cpp, line 189
> > 
> >
> > Why this change?

because currently it's not a text file. I can commit separately if you want.


- Aleix


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


On Dec. 14, 2015, 6:11 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126348/
> ---
> 
> (Updated Dec. 14, 2015, 6:11 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: kpackage
> 
> 
> Description
> ---
> 
> Due to KCoreAddons transition from using desktop files to json files, 
> KPackage ended in a weird state where desktop files were allowed to use 
> desktop files but not json.
> 
> This patch makes sure that manifest.json files are also acceptable.
> 
> 
> Diffs
> -
> 
>   autotests/querytest.cpp 0a2f11a 
>   src/kpackage/package.cpp 8416054 
>   src/kpackage/packageloader.cpp 1e1e382 
>   src/kpackage/private/packagejobthread.cpp 444dacc 
>   src/kpackage/private/packagejobthread_p.h 1babf0b 
>   src/kpackage/private/packages.cpp 2f6bbcf 
> 
> Diff: https://git.reviewboard.kde.org/r/126348/diff/
> 
> 
> Testing
> ---
> 
> Tests still pass (except for 
> https://build.kde.org/job/kpackage%20master%20stable-kf5-qt5/37/PLATFORM=Linux,compiler=gcc/testReport/,
>  that is not passing in master).
> Adds a test plugin with a json file in it.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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

Re: Review Request 126348: Make it possible to provide the metadata in json

2015-12-15 Thread Aleix Pol Gonzalez


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

(Updated Dec. 15, 2015, 4:24 p.m.)


Review request for KDE Frameworks and Plasma.


Changes
---

Address some issues.


Repository: kpackage


Description
---

Due to KCoreAddons transition from using desktop files to json files, KPackage 
ended in a weird state where desktop files were allowed to use desktop files 
but not json.

This patch makes sure that manifest.json files are also acceptable.


Diffs (updated)
-

  autotests/data/testjsonmetadatapackage/contents/ui/main.qml PRE-CREATION 
  autotests/data/testjsonmetadatapackage/metadata.json PRE-CREATION 
  autotests/querytest.cpp 0a2f11a 
  src/kpackage/package.cpp 8416054 
  src/kpackage/packageloader.cpp 1e1e382 
  src/kpackage/private/packagejobthread.cpp 444dacc 
  src/kpackage/private/packages.cpp 2f6bbcf 

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


Testing
---

Tests still pass (except for 
https://build.kde.org/job/kpackage%20master%20stable-kf5-qt5/37/PLATFORM=Linux,compiler=gcc/testReport/,
 that is not passing in master).
Adds a test plugin with a json file in it.


Thanks,

Aleix Pol Gonzalez

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

Re: Review Request 126364: [server] Add Display::seats() -> QVector

2015-12-15 Thread Bhushan Shah


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

Ship it!


Ship It!

- Bhushan Shah


On Dec. 15, 2015, 8:19 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126364/
> ---
> 
> (Updated Dec. 15, 2015, 8:19 p.m.)
> 
> 
> Review request for Plasma, Bhushan Shah and Sebastian Kügler.
> 
> 
> Repository: kwayland
> 
> 
> Description
> ---
> 
> Similar to OutputInterfaces we can have multiple SeatInterfaces so
> expose a way to get to all SeatInterfaces.
> 
> 
> Diffs
> -
> 
>   autotests/server/test_seat.cpp 75f93fe0d38eca651773632c060a2b2a5faa47eb 
>   src/server/display.h 154e0f0b4c00375ca7d7f0a980392877fe743f50 
>   src/server/display.cpp 81ea7316e3b77f6db95748339d3dfaa30d33 
> 
> Diff: https://git.reviewboard.kde.org/r/126364/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

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

Review Request 126364: [server] Add Display::seats() -> QVector


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

Review request for Plasma, Bhushan Shah and Sebastian Kügler.


Repository: kwayland


Description
---

Similar to OutputInterfaces we can have multiple SeatInterfaces so
expose a way to get to all SeatInterfaces.


Diffs
-

  autotests/server/test_seat.cpp 75f93fe0d38eca651773632c060a2b2a5faa47eb 
  src/server/display.h 154e0f0b4c00375ca7d7f0a980392877fe743f50 
  src/server/display.cpp 81ea7316e3b77f6db95748339d3dfaa30d33 

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


Testing
---


Thanks,

Martin Gräßlin

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

Re: Review Request 126175: Click on item in plasmashell case focus stays on last pointed item

2015-12-15 Thread Anthony Fieroni


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

(Updated Дек. 15, 2015, 4:44 след обяд)


Status
--

This change has been discarded.


Review request for Plasma, David Edmundson, Martin Gräßlin, and Marco Martin.


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


Repository: plasma-workspace


Description
---

You can see videos in bug repot


Diffs
-

  shell/panelview.cpp 3407501 

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


Testing
---

I test patch and all works as expected.
http://doc.qt.io/qt-5/qevent.html
QEvent::Leave   11  Mouse leaves widget's boundaries.


Thanks,

Anthony Fieroni

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

Re: Review Request 126175: Click on item in plasmashell case focus stays on last pointed item

2015-12-15 Thread Anthony Fieroni



> On Дек. 15, 2015, 4:14 след обяд, David Edmundson wrote:
> > your new patch supercedes this right?

Yes, this was old :)


- Anthony


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


On Дек. 2, 2015, 6:59 преди обяд, Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126175/
> ---
> 
> (Updated Дек. 2, 2015, 6:59 преди обяд)
> 
> 
> Review request for Plasma, David Edmundson, Martin Gräßlin, and Marco Martin.
> 
> 
> Bugs: 354651
> https://bugs.kde.org/show_bug.cgi?id=354651
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> You can see videos in bug repot
> 
> 
> Diffs
> -
> 
>   shell/panelview.cpp 3407501 
> 
> Diff: https://git.reviewboard.kde.org/r/126175/diff/
> 
> 
> Testing
> ---
> 
> I test patch and all works as expected.
> http://doc.qt.io/qt-5/qevent.html
> QEvent::Leave 11  Mouse leaves widget's boundaries.
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>

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

Re: Review Request 126356: change minimum size of clipboard


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



applets/clipboard/contents/ui/clipboard.qml (line 69)


this is not the actual size of the systray, but a hardcoded value which 
might match (or not) the size of systray.

As the motivation sounds correct to me I suggest to find a way to actually 
use the size of systray. Experts around?


- Martin Gräßlin


On Dec. 15, 2015, 1:37 p.m., andreas kainz wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126356/
> ---
> 
> (Updated Dec. 15, 2015, 1:37 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> if you use clipboard on the desktop the minimum window height is heigher than 
> you use clipboard from the panel (drop down window). As the user can define 
> the width and height for the desktop plasmoid the minimum allowed height 
> should be at least the same than the drop down window in the panel. so I 
> change the minimumHeig to 16.
> 
> 
> Diffs
> -
> 
>   applets/clipboard/contents/ui/clipboard.qml 97230c1 
> 
> Diff: https://git.reviewboard.kde.org/r/126356/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> old before with 26 min height
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/12/15/cdc4e222-a954-4f92-816f-521f35aab7c7__clipboard-alt_.png
> new after with 16 min height
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/12/15/50773744-a980-4091-8ef2-7eec516cb597__clipboard-new_.png
> 
> 
> Thanks,
> 
> andreas kainz
> 
>

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

Jenkins-kde-ci: plasma-workspace Plasma-5.5 stable-kf5-qt5 » Linux,gcc - Build # 19 - Still Failing!

2015-12-15 Thread no-reply


GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/plasma-workspace%20Plasma-5.5%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/19/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Tue, 15 Dec 2015 13:26:58 +
Build duration: 1 min 51 sec

CHANGE SET
Revision a0578e6e5dbd429366e6a9837af543a4c85b5a75 by David Edmundson: 
(Workaround a system icon tray issue in bug)
  change: edit applets/systemtray/plugin/host.cpp
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126175: Click on item in plasmashell case focus stays on last pointed item


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


your new patch supercedes this right?

- David Edmundson


On Dec. 2, 2015, 4:59 a.m., Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126175/
> ---
> 
> (Updated Dec. 2, 2015, 4:59 a.m.)
> 
> 
> Review request for Plasma, David Edmundson, Martin Gräßlin, and Marco Martin.
> 
> 
> Bugs: 354651
> https://bugs.kde.org/show_bug.cgi?id=354651
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> You can see videos in bug repot
> 
> 
> Diffs
> -
> 
>   shell/panelview.cpp 3407501 
> 
> Diff: https://git.reviewboard.kde.org/r/126175/diff/
> 
> 
> Testing
> ---
> 
> I test patch and all works as expected.
> http://doc.qt.io/qt-5/qevent.html
> QEvent::Leave 11  Mouse leaves widget's boundaries.
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>

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

Re: Review Request 126357: Workaround a system icon tray issue in bug 352055

2015-12-15 Thread Xuetian Weng


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

(Updated Dec. 15, 2015, 2:13 p.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma and David Edmundson.


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


Repository: plasma-workspace


Description
---

For whatever reason (probably inside Qt itself), this specific change can 
workaround one of causes of bug 352055 for people hitting disappeared icon in 
system tray.

For why this is different from the current implementation, see 
https://bugs.kde.org/show_bug.cgi?id=352055#c38

There seems to be two different bug in 352055 but looks similar, the other one 
is fixed in Qt 5.6 according to Albert Astals Cid.


Diffs
-

  applets/systemtray/plugin/host.cpp 61e8705 

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


Testing
---

At least fix my problem here locally.


Thanks,

Xuetian Weng

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

meeting in < 1 hour

2015-12-15 Thread Jonathan Riddell

5.6 kickoff meeting in #plasma in < 1 hour
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126363: Use gridUnit for default panel thickness


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

(Updated Dec. 15, 2015, 2:01 p.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma.


Changes
---

Submitted with commit eed2f0206184a5066038a6dea7402f24634fb72e by Eike Hein to 
branch Plasma/5.5.


Repository: plasma-desktop


Description
---

This makes the initial panel thickness scale.

I've removed the calculation taking screen res into account because res != 
physical size, and this is not actually working on my three systems 
(screenGeometry.height() is always 0), nor have I seen proportionally larger 
panels on screenshots. If it's not working it means nobody is used to getting a 
larger panel, nor have there been complaints, so we can drop this complexity. 
It also means we don't have to work in half-gridUnits to get close to the 
original value (if you assume the original delta was chosen on a 96 dpi system).


Diffs
-

  layout-templates/org.kde.plasma.desktop.defaultPanel/contents/layout.js 
46b1f3b 

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


Testing
---

Default panel thickness now comes out as 28px instead of 27px on a 96 dpi test 
system.


Thanks,

Eike Hein

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

Re: Review Request 126363: Use gridUnit for default panel thickness


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

Ship it!


I like it ;)

- Marco Martin


On Dec. 15, 2015, 1:38 p.m., Eike Hein wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126363/
> ---
> 
> (Updated Dec. 15, 2015, 1:38 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> This makes the initial panel thickness scale.
> 
> I've removed the calculation taking screen res into account because res != 
> physical size, and this is not actually working on my three systems 
> (screenGeometry.height() is always 0), nor have I seen proportionally larger 
> panels on screenshots. If it's not working it means nobody is used to getting 
> a larger panel, nor have there been complaints, so we can drop this 
> complexity. It also means we don't have to work in half-gridUnits to get 
> close to the original value (if you assume the original delta was chosen on a 
> 96 dpi system).
> 
> 
> Diffs
> -
> 
>   layout-templates/org.kde.plasma.desktop.defaultPanel/contents/layout.js 
> 46b1f3b 
> 
> Diff: https://git.reviewboard.kde.org/r/126363/diff/
> 
> 
> Testing
> ---
> 
> Default panel thickness now comes out as 28px instead of 27px on a 96 dpi 
> test system.
> 
> 
> Thanks,
> 
> Eike Hein
> 
>

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

Review Request 126363: Use gridUnit for default panel thickness


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

Review request for Plasma.


Repository: plasma-desktop


Description
---

This makes the initial panel thickness scale.

I've removed the calculation taking screen res into account because res != 
physical size, and this is not actually working on my three systems 
(screenGeometry.height() is always 0), nor have I seen proportionally larger 
panels on screenshots. If it's not working it means nobody is used to getting a 
larger panel, nor have there been complaints, so we can drop this complexity. 
It also means we don't have to work in half-gridUnits to get close to the 
original value (if you assume the original delta was chosen on a 96 dpi system).


Diffs
-

  layout-templates/org.kde.plasma.desktop.defaultPanel/contents/layout.js 
46b1f3b 

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


Testing
---

Default panel thickness now comes out as 28px instead of 27px on a 96 dpi test 
system.


Thanks,

Eike Hein

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

Jenkins-kde-ci: plasma-workspace Plasma-5.5 stable-kf5-qt5 » Linux,gcc - Build # 18 - Still Failing!

2015-12-15 Thread no-reply


GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/plasma-workspace%20Plasma-5.5%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/18/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Tue, 15 Dec 2015 12:50:46 +
Build duration: 1 min 56 sec

CHANGE SET
Revision 1390b40b399770e7a67da714c74d172eee1bb433 by David Edmundson: (Fix left 
click on item in panel being ignored)
  change: edit shell/panelview.cpp
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126349: Add screenPixelRatio(int screen) to desktop scripting API


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

(Updated Dec. 15, 2015, 1:15 p.m.)


Status
--

This change has been discarded.


Review request for Plasma and David Edmundson.


Repository: plasma-workspace


Description
---

This adds a global function qreal screenPixelRatio(int screen) to the desktop 
scripting API to complement screenGeometry(). Since we don't do per-screen 
scaling in Plasma currently the implementation ignores the argument. It's 
otherwise matching Units::devicePixelRatio.

If this becomes available, I can use it in the default panel layout script to 
scale the default panel thickness, which is currently unscaled - i.e. when 
Plasma scales up on a hi-dpi screen the panel will be initialized to be tiny 
anyway, which is a pretty egregrious papercut on hidpi systems.


Diffs
-

  shell/scripting/appinterface.h 93aa014 
  shell/scripting/appinterface.cpp 2c54f1e 

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


Testing
---

Adjusted layout script, determined it works nicely.


Thanks,

Eike Hein

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

Plasma 5.5.1

2015-12-15 Thread Jonathan Riddell

Plasma 5.5.1 is now released https://www.kde.org/announcements/plasma-5.5.1.php
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126357: Workaround a system icon tray issue in bug 352055


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


tagging is today, so I pushed for you, hope that's ok.

- David Edmundson


On Dec. 15, 2015, 4:44 a.m., Xuetian Weng wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126357/
> ---
> 
> (Updated Dec. 15, 2015, 4:44 a.m.)
> 
> 
> Review request for Plasma and David Edmundson.
> 
> 
> Bugs: 352055
> https://bugs.kde.org/show_bug.cgi?id=352055
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> For whatever reason (probably inside Qt itself), this specific change can 
> workaround one of causes of bug 352055 for people hitting disappeared icon in 
> system tray.
> 
> For why this is different from the current implementation, see 
> https://bugs.kde.org/show_bug.cgi?id=352055#c38
> 
> There seems to be two different bug in 352055 but looks similar, the other 
> one is fixed in Qt 5.6 according to Albert Astals Cid.
> 
> 
> Diffs
> -
> 
>   applets/systemtray/plugin/host.cpp 61e8705 
> 
> Diff: https://git.reviewboard.kde.org/r/126357/diff/
> 
> 
> Testing
> ---
> 
> At least fix my problem here locally.
> 
> 
> Thanks,
> 
> Xuetian Weng
> 
>

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

Re: Review Request 126331: Left click on item in task manager is ignored, arbitrary

2015-12-15 Thread Anthony Fieroni

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

(Updated Dec. 15, 2015, 12:50 p.m.)

Status
--

This change has been marked as submitted.

Review request for Plasma and David Edmundson.

Changes
---

Submitted with commit 1390b40b399770e7a67da714c74d172eee1bb433 by David
Edmundson on behalf of Anthony Fieroni to branch Plasma/5.5.

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

Repository: plasma-workspace

Description
---

Last patch has a reggression due to QtQuick issue (only on Xcb): QEvent::Leave
is triggered after QEvent::MouseButtonPress Qt::LeftButton

Diffs
-

shell/panelview.cpp 063343d

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

Testing
---

This QtQuick (Xcb) issue (on Wayland works fine) can be found and on Comic
Strip ('show arrows on mouse over' in settings) every first click on arrow is
ignored. I'm not familiar with Qt, if this bug is fixed or Qt devs must be
noticed for this behavior. During patch testing i found other bug, when drag an
item from task manager and drop in the desktop, on desktop is created a
shortcut, but this works only when widgets are unlocked, if they are locked
drop cause a crash, a backtrace present.

File Attachments

plasmashell-20151213-132332.kcrash.txt

https://git.reviewboard.kde.org/media/uploaded/files/2015/12/13/3720870f-3827-41c3-b522-1a2ac5a5611a__plasmashell-20151213-132332.kcrash.txt

Thanks,

Anthony Fieroni

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

Re: Review Request 126357: Workaround a system icon tray issue in bug 352055


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


This isn't really a workaround, it's what the code was originally trying to be 
doing. 

The former is wrong as it actually starts a timer

- David Edmundson


On Dec. 15, 2015, 4:44 a.m., Xuetian Weng wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126357/
> ---
> 
> (Updated Dec. 15, 2015, 4:44 a.m.)
> 
> 
> Review request for Plasma and David Edmundson.
> 
> 
> Bugs: 352055
> https://bugs.kde.org/show_bug.cgi?id=352055
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> For whatever reason (probably inside Qt itself), this specific change can 
> workaround one of causes of bug 352055 for people hitting disappeared icon in 
> system tray.
> 
> For why this is different from the current implementation, see 
> https://bugs.kde.org/show_bug.cgi?id=352055#c38
> 
> There seems to be two different bug in 352055 but looks similar, the other 
> one is fixed in Qt 5.6 according to Albert Astals Cid.
> 
> 
> Diffs
> -
> 
>   applets/systemtray/plugin/host.cpp 61e8705 
> 
> Diff: https://git.reviewboard.kde.org/r/126357/diff/
> 
> 
> Testing
> ---
> 
> At least fix my problem here locally.
> 
> 
> Thanks,
> 
> Xuetian Weng
> 
>

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

Re: Review Request 126357: Workaround a system icon tray issue in bug 352055


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

Ship it!


Ship It!

- David Edmundson


On Dec. 15, 2015, 4:44 a.m., Xuetian Weng wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126357/
> ---
> 
> (Updated Dec. 15, 2015, 4:44 a.m.)
> 
> 
> Review request for Plasma and David Edmundson.
> 
> 
> Bugs: 352055
> https://bugs.kde.org/show_bug.cgi?id=352055
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> For whatever reason (probably inside Qt itself), this specific change can 
> workaround one of causes of bug 352055 for people hitting disappeared icon in 
> system tray.
> 
> For why this is different from the current implementation, see 
> https://bugs.kde.org/show_bug.cgi?id=352055#c38
> 
> There seems to be two different bug in 352055 but looks similar, the other 
> one is fixed in Qt 5.6 according to Albert Astals Cid.
> 
> 
> Diffs
> -
> 
>   applets/systemtray/plugin/host.cpp 61e8705 
> 
> Diff: https://git.reviewboard.kde.org/r/126357/diff/
> 
> 
> Testing
> ---
> 
> At least fix my problem here locally.
> 
> 
> Thanks,
> 
> Xuetian Weng
> 
>

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

Re: Review Request 126356: change minimum size of clipboard


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

(Updated Dec. 15, 2015, 12:37 p.m.)


Review request for Plasma.


Changes
---

the minimum height of the desktop widget was changed.


Repository: plasma-workspace


Description
---

if you use clipboard on the desktop the minimum window height is heigher than 
you use clipboard from the panel (drop down window). As the user can define the 
width and height for the desktop plasmoid the minimum allowed height should be 
at least the same than the drop down window in the panel. so I change the 
minimumHeig to 16.


Diffs
-

  applets/clipboard/contents/ui/clipboard.qml 97230c1 

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


Testing
---


File Attachments (updated)


old before with 26 min height
  
https://git.reviewboard.kde.org/media/uploaded/files/2015/12/15/cdc4e222-a954-4f92-816f-521f35aab7c7__clipboard-alt_.png
new after with 16 min height
  
https://git.reviewboard.kde.org/media/uploaded/files/2015/12/15/50773744-a980-4091-8ef2-7eec516cb597__clipboard-new_.png


Thanks,

andreas kainz

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

Re: Review Request 119658: [WIP] Support per-activity favourites in Kicker

2015-12-15 Thread Ivan Čukić


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

(Updated Dec. 15, 2015, 11:10 a.m.)


Status
--

This change has been discarded.


Review request for Plasma, Eike Hein and Marco Martin.


Repository: plasma-desktop


Description
---

Basic changes to support KActivities.ResourceModel-based favourites in Kicker.

What works:
- Favourites are shown
- They can be added and removed
- Shared with other launchers (currently kickoff)
 
What does not (request for comments):
- launching the favourites

  KActivities.ResourceModel does not have a method to open an URL, while Kicker 
relies on the 'trigger' method. The important question to discuss is whether it 
should know that at all, or it should leave launching to the client application 
(like kickoff currently does).
  From my POV, the model *needs* to only provide the URL, and the application 
should know how to open the URL it provided to the model in the first place. It 
*could* have a (convenience) method to launch the URL, but there will be a lot 
of URLs that it can not understand (like akonadi:something, etc.). The 
convenience method would be useful in a few places, not only Kicker.
  
- drag'n'drop rearanging does not work

  KActivities.ResourceModel is based on QSortFilterProxyModel. This means that 
whenever an item is moved from one place to another, the model reloads itself 
(at least, the client sees it as a reload).
  This QSFPM behaviour collides with the d'n'd implementation in Kicker (as 
opposed to Kickoff) because it does the d'n'd by moving an item one place at a 
time, instead of moving it directly to the destination. That is, if an item is 
moved from 2nd to 5th position, Kicker will move it 2nd->3rd, 3rd->4th, 
4th->5th. The model will invalidate the dragged item on the first step, and 
other steps will not work.
  
I need ideas and opinions for these issues.

Cheers!


Diffs
-

  applets/kicker/package/contents/ui/SideBarSection.qml 0411545 
  applets/kicker/plugin/favoritesmodel.h 342d3d1 
  applets/kicker/plugin/favoritesmodel.cpp 3494a65 

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


Testing
---


Thanks,

Ivan Čukić

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

Re: Review Request 119515: Support per-activity favourites for Kickoff

2015-12-15 Thread Ivan Čukić


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

(Updated Dec. 15, 2015, 11:09 a.m.)


Status
--

This change has been discarded.


Review request for Plasma, Eike Hein, Marco Martin, and Sebastian Kügler.


Repository: plasma-desktop


Description
---

This patch adds the support to have favourites linked to activities.

It uses org.kde.activities.ResourceModel to show favorites.

It supports:
 - adding a favourite to all activities (the previous behaviour)
 - adding a favourite to the current activity
 - moving a favourite between 'all activities' and 'current activity' modes (it 
does not affect non-current activities)
 - drag-and-drop reordering of items (like the previous one)
 - sorting A-Z, Z-A (like the previous one)
 - transitions previously defined favourites to the new system*

Context menu item captions could maybe use some improvement.

Screenshot available at: 
http://ivan.fomentgroup.org/blog/2014/07/27/per-activity-favourites-in-kickoff/#/comments

* this can also be used for defining the default favourites in a global 
kickoffrc file - instead of them being hard-coded like they currently are.


Diffs
-

  applets/kickoff/CMakeLists.txt 28e7029 
  applets/kickoff/core/favoritesmodel.h 27a0626 
  applets/kickoff/core/favoritesmodel.cpp f05588b 
  applets/kickoff/core/kickoffplugin.cpp f549981 
  applets/kickoff/core/krunnermodel.h 3916829 
  applets/kickoff/core/krunnermodel.cpp db2adab 
  applets/kickoff/package/contents/ui/ContextMenu.qml 6a67874 
  applets/kickoff/package/contents/ui/FavoritesView.qml 6c2d5d4 
  applets/kickoff/package/contents/ui/FullRepresentation.qml 6291b7c 

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


Testing
---

Yes


Thanks,

Ivan Čukić

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

Re: Review Request 124655: Cosmetic surgery of the activity switcher

2015-12-15 Thread Ivan Čukić


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

(Updated Dec. 15, 2015, 11:09 a.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma and Marco Martin.


Repository: plasma-desktop


Description
---

- Refactoring the dialog handling
- Dialogs are now truly inline
- Fixed a few layout and positioning bugs


Diffs
-

  desktoppackage/contents/activitymanager/ActivityCreationDialog.qml 49e9b96 
  desktoppackage/contents/activitymanager/ActivityDeletionDialog.qml f189b4d 
  desktoppackage/contents/activitymanager/ActivityItem.qml bfd83a0 
  desktoppackage/contents/activitymanager/ActivityList.qml 97667a7 
  desktoppackage/contents/activitymanager/ActivityManager.qml 9da8054 
  desktoppackage/contents/activitymanager/StoppedActivityItem.qml c5dcb98 
  desktoppackage/contents/activitymanager/static.js PRE-CREATION 

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


Testing
---


Thanks,

Ivan Čukić

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

Jenkins-kde-ci: plasma-workspace Plasma-5.5 stable-kf5-qt5 » Linux,gcc - Build # 17 - Still Failing!

2015-12-15 Thread no-reply


GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/plasma-workspace%20Plasma-5.5%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/17/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Tue, 15 Dec 2015 10:08:05 +
Build duration: 1 min 4 sec

CHANGE SET
Revision 4182cf5efa4a6ed0115fb1a0a58593387914751b by Jonathan Riddell: (Update 
version number for 5.5.1 GIT_SILENT)
  change: edit CMakeLists.txt
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126064: [DragArea] Add dragActive property


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

(Updated Dec. 15, 2015, 10:43 a.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma.


Changes
---

Submitted with commit 83ac45466e817dd1973dff1e502463fea1d88921 by Kai Uwe 
Broulik to branch master.


Repository: kdeclarative


Description
---

It allows to query whether a drag is currently ongoing. This eases avoiding 
dropping something onto itself when it has both DragArea and DropArea


Diffs
-

  src/qmlcontrols/draganddrop/DeclarativeDragArea.h 6cb682d 
  src/qmlcontrols/draganddrop/DeclarativeDragArea.cpp 3afaa62 

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


Testing
---

Works


Thanks,

Kai Uwe Broulik

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

Re: Review Request 126185: Make the KAppTemplate CMake module global



> On Dec. 12, 2015, 3:40 p.m., Alex Merry wrote:
> > Ooh, also, please write a unit test. I can help with that if you find the 
> > idea of writing a CMake-based unit test daunting, but you can look in the 
> > tests directory for inspiration.

I'm not sure what the test should do...
perhaps having in the repo a tarball and a source template, make it generate 
and then compare the files?


- Marco


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


On Dec. 15, 2015, 10:38 a.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126185/
> ---
> 
> (Updated Dec. 15, 2015, 10:38 a.m.)
> 
> 
> Review request for Build System, KDE Frameworks, Plasma, Aleix Pol Gonzalez, 
> and Simon Wächter.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> templates are very useful as teaching tool in order to make
> a minimal application that uses a certain framework.
> templates in the KAppTemplate repository will always get forgotten
> (plus kapptemplate is not really necessary as they work in kdevelop as well)
> An ideal situation would be frameworks having templates in their own repos
> with templates of barebone apps using the main framework features.
> In order to do that, the cmake stuff needed in order to correctly install
> a template needs to be ported to a place avaiable to all frameworks
> 
> 
> Diffs
> -
> 
>   kde-modules/KDEInstallDirs.cmake b7cd34d 
>   kde-modules/KDETemplateGenerator.cmake PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/126185/diff/
> 
> 
> Testing
> ---
> 
> done some templates installed by plasma-framework
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

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

Re: Review Request 126185: Make the KAppTemplate CMake module global


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

(Updated Dec. 15, 2015, 10:38 a.m.)


Review request for Build System, KDE Frameworks, Plasma, Aleix Pol Gonzalez, 
and Simon Wächter.


Repository: extra-cmake-modules


Description
---

templates are very useful as teaching tool in order to make
a minimal application that uses a certain framework.
templates in the KAppTemplate repository will always get forgotten
(plus kapptemplate is not really necessary as they work in kdevelop as well)
An ideal situation would be frameworks having templates in their own repos
with templates of barebone apps using the main framework features.
In order to do that, the cmake stuff needed in order to correctly install
a template needs to be ported to a place avaiable to all frameworks


Diffs (updated)
-

  kde-modules/KDEInstallDirs.cmake b7cd34d 
  kde-modules/KDETemplateGenerator.cmake PRE-CREATION 

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


Testing
---

done some templates installed by plasma-framework


Thanks,

Marco Martin

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

Re: Review Request 126292: [CompactApplet] Hack to force focus on expanded representation


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

(Updated Dec. 15, 2015, 10:35 a.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma.


Changes
---

Submitted with commit cb583af2b39317f3500306ce6d0644136d170d88 by Kai Uwe 
Broulik to branch Plasma/5.5.


Repository: plasma-desktop


Description
---

By default the Dialog's mainItem (some QQuickRootSomething item) has focus 
which doesn't seem to forward any key events. To workaround this I force focus 
on the actual expanded representation in case it didn't already force it 
elsewhere.


Diffs
-

  desktoppackage/contents/applet/CompactApplet.qml cbc222e 

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


Testing
---

I now get keyboard events to plasma popups that just use Keys instead of 
manually messing with focus like Kickoff but I'm open to better suggestions :)


Thanks,

Kai Uwe Broulik

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

Re: Review Request 126185: Make the KAppTemplate CMake module global



> On Dec. 12, 2015, 3:35 p.m., Alex Merry wrote:
> > kde-modules/KDETemplateGenerator.cmake, line 14
> > 
> >
> > OK, what needs to be in the subdirectory? are template1, template2 etc 
> > the subdriectory names? The packages file name?
> > 
> > The following sentence suggests this command only creates a single 
> > template tarball, but the signature here has multiple arguments.
> > 
> > Also, the command doesn't need to include the word "template" twice. I 
> > suggest kde_add_app_template.
> > 
> > Finally, the signature now includes the TEMPLATES keyword.

the subdirectories have the uncompressed templates in it
the subdirectory names will correspond to the final package name.


> On Dec. 12, 2015, 3:35 p.m., Alex Merry wrote:
> > kde-modules/KDETemplateGenerator.cmake, line 84
> > 
> >
> > Use ``KDE_INSTALL_KTEMPLATESDIR`` instead of 
> > ``KTEMPLATES_INSTALL_DIR``. You also need to document that this variable 
> > needs to be set before using the command.
> > 
> > My preference would actually be to make it explicit in the signature 
> > that installation will happen, by having the usage be something like
> > 
> > kde_package_app_templates(
> > TEMPLATES
> > foo
> > bar
> > baz
> > INSTALL_DIR
> > "${KDE_INSTALL_KTEMPLATESDIR}"
> > )
> > 
> > My view is that this makes it explicit what will happen when you're 
> > reading the code - it will package the templates and install them. But I'm 
> > not going to force your hand on this if you'd rather not do it that way.

would it still take ${KDE_INSTALL_KTEMPLATESDIR} as default or would be 
mandatory to be passed by the caller?


- Marco


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


On Dec. 9, 2015, 12:12 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126185/
> ---
> 
> (Updated Dec. 9, 2015, 12:12 p.m.)
> 
> 
> Review request for Build System, KDE Frameworks, Plasma, Aleix Pol Gonzalez, 
> and Simon Wächter.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> templates are very useful as teaching tool in order to make
> a minimal application that uses a certain framework.
> templates in the KAppTemplate repository will always get forgotten
> (plus kapptemplate is not really necessary as they work in kdevelop as well)
> An ideal situation would be frameworks having templates in their own repos
> with templates of barebone apps using the main framework features.
> In order to do that, the cmake stuff needed in order to correctly install
> a template needs to be ported to a place avaiable to all frameworks
> 
> 
> Diffs
> -
> 
>   kde-modules/KDETemplateGenerator.cmake PRE-CREATION 
>   kde-modules/KDEInstallDirs.cmake b7cd34d 
> 
> Diff: https://git.reviewboard.kde.org/r/126185/diff/
> 
> 
> Testing
> ---
> 
> done some templates installed by plasma-framework
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

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

Re: Review Request 126292: [CompactApplet] Hack to force focus on expanded representation


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

Ship it!


Ship It!

- Marco Martin


On Dec. 13, 2015, 7:48 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126292/
> ---
> 
> (Updated Dec. 13, 2015, 7:48 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> By default the Dialog's mainItem (some QQuickRootSomething item) has focus 
> which doesn't seem to forward any key events. To workaround this I force 
> focus on the actual expanded representation in case it didn't already force 
> it elsewhere.
> 
> 
> Diffs
> -
> 
>   desktoppackage/contents/applet/CompactApplet.qml cbc222e 
> 
> Diff: https://git.reviewboard.kde.org/r/126292/diff/
> 
> 
> Testing
> ---
> 
> I now get keyboard events to plasma popups that just use Keys instead of 
> manually messing with focus like Kickoff but I'm open to better suggestions :)
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

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

Re: Review Request 126349: Add screenPixelRatio(int screen) to desktop scripting API