Build failed in Jenkins: plasma-workspace_master_qt5 #990

[KDE CI System]

See 

Changes:

[montel] Fix includes

[montel] Remove kdelibs4support

[montel] Remove not necessary include moc

[montel] Remove not necessary include moc

[montel] Remove deprecated function

[montel] Fix includes

[montel] Port to new connect api

--
[...truncated 2720 lines...]
Linking CXX shared module plasma_engine_packagekit.so
[ 69%] Built target plasma_engine_packagekit
[ 69%] Building CXX object 
dataengines/mpris2/CMakeFiles/plasma_engine_mpris2.dir/playercontrol.cpp.o
[ 70%] Generating krunner_interface.cpp, krunner_interface.h
Scanning dependencies of target plasma_engine_places
[ 70%] Building CXX object 
dataengines/places/CMakeFiles/plasma_engine_places.dir/placesengine.cpp.o
[ 70%] Generating krunner_interface.moc
[ 70%] Building CXX object 
dataengines/places/CMakeFiles/plasma_engine_places.dir/placeservice.cpp.o
Scanning dependencies of target plasma_engine_powermanagement
[ 70%] Building CXX object 
dataengines/powermanagement/CMakeFiles/plasma_engine_powermanagement.dir/powermanagementengine.cpp.o
[ 70%] Building CXX object 
dataengines/powermanagement/CMakeFiles/plasma_engine_powermanagement.dir/powermanagementjob.cpp.o
[ 70%] Building CXX object 
dataengines/powermanagement/CMakeFiles/plasma_engine_powermanagement.dir/powermanagementservice.cpp.o
[ 70%] Building CXX object 
dataengines/powermanagement/CMakeFiles/plasma_engine_powermanagement.dir/krunner_interface.cpp.o
[ 70%] Building CXX object 
dataengines/powermanagement/CMakeFiles/plasma_engine_powermanagement.dir/plasma_engine_powermanagement_automoc.cpp.o
Linking CXX shared module plasma_engine_notifications.so
[ 70%] Built target plasma_engine_notifications
[ 70%] Building CXX object 
dataengines/mpris2/CMakeFiles/plasma_engine_mpris2.dir/playeractionjob.cpp.o
[ 70%] Building CXX object 
dataengines/mpris2/CMakeFiles/plasma_engine_mpris2.dir/playercontainer.cpp.o
:
 In member function ‘virtual bool 
PowermanagementEngine::sourceRequestEvent(const QString&)’:
:174:41:
 warning: ‘Solid::PowerManagement::Notifier* 
Solid::PowerManagement::notifier()’ is deprecated (declared at 
/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/solid/powermanagement.h:154)
 [-Wdeprecated-declarations]
 connect(Solid::PowerManagement::notifier(), 
SIGNAL(appShouldConserveResourcesChanged(bool)),
 ^
:174:50:
 warning: ‘Solid::PowerManagement::Notifier* 
Solid::PowerManagement::notifier()’ is deprecated (declared at 
/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/solid/powermanagement.h:154)
 [-Wdeprecated-declarations]
 connect(Solid::PowerManagement::notifier(), 
SIGNAL(appShouldConserveResourcesChanged(bool)),
  ^
:176:51:
 warning: ‘bool Solid::PowerManagement::appShouldConserveResources()’ is 
deprecated (declared at 
/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/solid/powermanagement.h:66)
 [-Wdeprecated-declarations]
 
updateAcPlugState(Solid::PowerManagement::appShouldConserveResources());
   ^
:176:78:
 warning: ‘bool Solid::PowerManagement::appShouldConserveResources()’ is 
deprecated (declared at 
/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/solid/powermanagement.h:66)
 [-Wdeprecated-declarations]
 
updateAcPlugState(Solid::PowerManagement::appShouldConserveResources());
  ^
:178:94:
 warning: ‘QSet 
Solid::PowerManagement::supportedSleepStates()’ is deprecated (declared at 
/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/solid/powermanagement.h:74)
 [-Wdeprecated-declarations]
 const QSet sleepstates = 
Solid::PowerManagement::supportedSleepStates();

  ^

Re: Review Request 120624: add gtkbreeze, kconf_update tool to set gtk settings on first login

[Jonathan Riddell]

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

(Updated Oct. 20, 2014, 9:11 p.m.)


Review request for Plasma and Hugo Pereira Da Costa.


Repository: breeze


Description
---

add gtkbreeze, kconf_update tool to set gtk settings on first login
this checks if gtk settings are already set, if they are not or are set to 
oxygen they update them, else it quits
it does this for both gtk 2 and 3
it sets gtk to the orion theme because it's available for both gtk 2 and 3 and 
it looks similar to breeze
it sets the icons to oxygen because I could not get breeze icons to work with 
gtk 2 or 3
I also could not get icons to show on buttons or in menus in gtk 3


Diffs (updated)
-

  misc/CMakeLists.txt ff891a9 
  misc/gtkbreeze/CMakeLists.txt PRE-CREATION 
  misc/gtkbreeze/gtkbreeze.upd PRE-CREATION 
  misc/gtkbreeze/main.cpp PRE-CREATION 

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


Testing
---

run it and run gtk-demo and gtk3-demo


Thanks,

Jonathan Riddell

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

Re: Review Request 120667: set the polkit helper id to let polkit change the settings

[Jonathan Riddell]

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

(Updated Oct. 20, 2014, 4:10 p.m.)


Status
--

This change has been discarded.


Review request for Plasma and David Edmundson.


Repository: plasma-desktop


Description
---

set the polkit helper id to let polkit change the settings.  without this the 
kcm just blocks when you click Apply.


but the key icons don't appear on the ok/apply buttons in kcmshell5 which makes 
me suspicious


Diffs
-

  kcms/dateandtime/main.cpp 0041a9d7b115b4e6f74973ff23a78fa619bd4a24 

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


Testing
---

installed and clicked apply


Thanks,

Jonathan Riddell

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

Re: Review Request 120667: set the polkit helper id to let polkit change the settings

[Jonathan Riddell]

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


On further reflection this may not be broken, it may just being slow

- Jonathan Riddell


On Oct. 20, 2014, 2:44 p.m., Jonathan Riddell wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120667/
> ---
> 
> (Updated Oct. 20, 2014, 2:44 p.m.)
> 
> 
> Review request for Plasma and David Edmundson.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> set the polkit helper id to let polkit change the settings.  without this the 
> kcm just blocks when you click Apply.
> 
> 
> but the key icons don't appear on the ok/apply buttons in kcmshell5 which 
> makes me suspicious
> 
> 
> Diffs
> -
> 
>   kcms/dateandtime/main.cpp 0041a9d7b115b4e6f74973ff23a78fa619bd4a24 
> 
> Diff: https://git.reviewboard.kde.org/r/120667/diff/
> 
> 
> Testing
> ---
> 
> installed and clicked apply
> 
> 
> Thanks,
> 
> Jonathan Riddell
> 
>

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

Re: The usage statistics [kactivities, baloo, ktp, plasma]

[Vishesh Handa]

On Mon, Oct 13, 2014 at 6:59 PM, Ivan Čukić  wrote:
>
> 3. What will be needed
> 
>
> Integration with baloo. It will require patches on both sides if we are to
> support all the use-cases without cross-queries. We will need accessible
> file
> types via sqlite (on baloo side) and baloo identifiers or something on kamd
> side.
>

* The Baloo identifiers will only work for indexed files. Given that we're
not enforcing users to index everything (nor should we). We need a
different approach.
* This would also require Baloo to stick with sqlite.

Appendix 1: Formula for the resource scoring:
> ===
>
> LaTeX formatted:
> S = \sum _{i = 1} ^ n
> e^{-d_i} e^{k_i \log(l_i)}
>
> Haskell-like formatted, whichever you find easier to read :)
> sum [
> exp (-di) * exp ( ki * log li ) | i <- [1..n]
> ]
>
> where d_i is the time that passed since the i-th event, k_i coefficient
> depending on the type of the event, l_i length of the event (time distance
> between open and close for example, or focus in and out)
>
> It can be rewritten to look prettier (exp log = id and so on), but this
> conveys the meaning in a nicer way by separating the terms according to
> their
> meaning.
>
> The main ideas behind the formula are:
>  - score degrades with the time, so if a document was kept open in okular
> for
> an hour yesterday, it will have a significantly higher score than a
> document
> that was kept open for a whole day a year ago;
>  - different events have different meanings;
>  - event time interval is measured on a logarithmic scale, so that there
> is a
> greater difference between 1hr and 2hrs, than between 11hrs and 12hrs;
>  - can be calculated quickly by only processing new events since the last
> score update.
>

I don't understand all of the math, but this sounds quite ideal. Currently
in KRunner we have a global run count which affects the score of all the
result, and that score doesn't degrade over time. This seems like something
nice to replace it with, if we can make it super fast that is.

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

Re: The usage statistics [kactivities, baloo, ktp, plasma]

[David Edmundson]

On Mon, Oct 20, 2014 at 4:53 PM, Ivan Čukić  wrote:

> > One use case that we might want to consider is including email frequency
>
> > when sorting contacts.
>
>
> Well, I'd say sent e-mail frequency. I don't care that some person is
> spamming
>
> me often - I do care if I'm spamming them. :)
>

Yes, I meant that too.


>
> > What makes this very different from the rest is that the length of event
>
> > doesn't really apply. I tend to write an email then fill in the address
>
> > last, so kmail couldn't give accurate stats if it tried. and the length
> of
>
> > time I spent typing might not have any impact.
>
>
> For that, there is the Accessed event - like open/close without the
> duration.
>
> The same is needed for application launchers - the launcher has no idea
> for
>
> how long an application was kept open, nor does it care.
>
>
> Perfect.


> > I'm a bit skeptical of the time tracking rather than usage tracking in
>
> > general, if a user opens something 10 times and closes that quickly, it's
>
>
> I guess it needs to be tested and coefficients adjusted.
>
>
> > once and leaves open. We might need to have an API that doesn't pass a
> wID
>
> > and just inserts an arbitrary time and/or a way to not put any weight on
>
>
> For that, the accessed event exists. WID is only for the things that want
> to
>
> end up in ShareLikeConnect
>
>
> Cheerio,
>
> Ivan
>
>
> KDE, ivan.cukic at kde.org, http://ivan.fomentgroup.org/
>
> gpg key id: 850B6F76, keyserver.pgp.com
>
>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: The usage statistics [kactivities, baloo, ktp, plasma]

[Ivan Čukić]

> One use case that we might want to consider is including email frequency

> when sorting contacts.


Well, I'd say sent e-mail frequency. I don't care that some person is
spamming

me often - I do care if I'm spamming them. :)


> What makes this very different from the rest is that the length of event

> doesn't really apply. I tend to write an email then fill in the address

> last, so kmail couldn't give accurate stats if it tried. and the length of

> time I spent typing might not have any impact.


For that, there is the Accessed event - like open/close without the
duration.

The same is needed for application launchers - the launcher has no idea for

how long an application was kept open, nor does it care.


> I'm a bit skeptical of the time tracking rather than usage tracking in

> general, if a user opens something 10 times and closes that quickly, it's


I guess it needs to be tested and coefficients adjusted.


> once and leaves open. We might need to have an API that doesn't pass a wID

> and just inserts an arbitrary time and/or a way to not put any weight on


For that, the accessed event exists. WID is only for the things that want
to

end up in ShareLikeConnect


Cheerio,

Ivan


KDE, ivan.cukic at kde.org, http://ivan.fomentgroup.org/

gpg key id: 850B6F76, keyserver.pgp.com
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 120667: set the polkit helper id to let polkit change the settings

[Lukáš Tinkl]

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

Ship it!


Weird, this was working just fine in 5.0... wondering what changed in KAuth

- Lukáš Tinkl


On Říj. 20, 2014, 4:44 odp., Jonathan Riddell wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120667/
> ---
> 
> (Updated Říj. 20, 2014, 4:44 odp.)
> 
> 
> Review request for Plasma and David Edmundson.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> set the polkit helper id to let polkit change the settings.  without this the 
> kcm just blocks when you click Apply.
> 
> 
> but the key icons don't appear on the ok/apply buttons in kcmshell5 which 
> makes me suspicious
> 
> 
> Diffs
> -
> 
>   kcms/dateandtime/main.cpp 0041a9d7b115b4e6f74973ff23a78fa619bd4a24 
> 
> Diff: https://git.reviewboard.kde.org/r/120667/diff/
> 
> 
> Testing
> ---
> 
> installed and clicked apply
> 
> 
> Thanks,
> 
> Jonathan Riddell
> 
>

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

Re: Review Request 120667: set the polkit helper id to let polkit change the settings

[David Edmundson]

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

Ship it!


Plasma 5.1 too.

- David Edmundson


On Oct. 20, 2014, 2:44 p.m., Jonathan Riddell wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120667/
> ---
> 
> (Updated Oct. 20, 2014, 2:44 p.m.)
> 
> 
> Review request for Plasma and David Edmundson.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> set the polkit helper id to let polkit change the settings.  without this the 
> kcm just blocks when you click Apply.
> 
> 
> but the key icons don't appear on the ok/apply buttons in kcmshell5 which 
> makes me suspicious
> 
> 
> Diffs
> -
> 
>   kcms/dateandtime/main.cpp 0041a9d7b115b4e6f74973ff23a78fa619bd4a24 
> 
> Diff: https://git.reviewboard.kde.org/r/120667/diff/
> 
> 
> Testing
> ---
> 
> installed and clicked apply
> 
> 
> Thanks,
> 
> Jonathan Riddell
> 
>

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

Re: Review Request 120667: set the polkit helper id to let polkit change the settings

[Jonathan Riddell]

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

(Updated Oct. 20, 2014, 2:44 p.m.)


Review request for Plasma and David Edmundson.


Repository: plasma-desktop


Description (updated)
---

set the polkit helper id to let polkit change the settings.  without this the 
kcm just blocks when you click Apply.


but the key icons don't appear on the ok/apply buttons in kcmshell5 which makes 
me suspicious


Diffs
-

  kcms/dateandtime/main.cpp 0041a9d7b115b4e6f74973ff23a78fa619bd4a24 

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


Testing
---

installed and clicked apply


Thanks,

Jonathan Riddell

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

Review Request 120667: set the polkit helper id to let polkit change the settings

[Jonathan Riddell]

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

Review request for Plasma and David Edmundson.


Repository: plasma-desktop


Description
---

set the polkit helper id to let polkit change the settings


Diffs
-

  kcms/dateandtime/main.cpp 0041a9d7b115b4e6f74973ff23a78fa619bd4a24 

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


Testing
---

installed and clicked apply


Thanks,

Jonathan Riddell

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

Plasma 5.2 Kickoff meeting

[Jonathan Riddell]

Let's have a Plasma 5.2 Kickoff meeting

In IRC in #plasma
pick some times to suit, remember to set the poll timezone for you
http://doodle.com/52cf8wu7vv5xcy8t

Agenda:
5.2 schedule, how to avoid beta depending on unreleased KF5
what 5.1 items to copy over:
https://todo.kde.org/?controller=board&action=show&project_id=1
what new 5.2 items

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

Re: Should touch events update the cursor position?

[Sebastian Kügler]

On Monday, October 20, 2014 15:56:01 Martin Gräßlin wrote:
> On Monday 20 October 2014 15:41:41 Sebastian Kügler wrote:
> > On Monday, October 20, 2014 15:35:55 Martin Gräßlin wrote:
> > > On Monday 20 October 2014 14:58:19 Sebastian Kügler wrote:
> > > 
> > >
> > > ok, but the events work, right? If you tap a button it does something?
> > > To
> > > me  it makes sense that the cursor doesn't move as the cursor belongs to
> > > the pointer device and not to the touch device.
> >
> > 
> >
> > Ah, yes. Tapping works. I hadn't tried, assuming if it doesn't move the
> > mouse cursor, tapping won't work either.
> 
> good, good. What I take from that is that in one way or another we need to 
> provide visual feedback when using the touch screen.

Yes. I think that'd be even nicer than updating the cursor position. Maybe a 
VDG-peron has input on how to visualize it?
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Should touch events update the cursor position?

[Martin Gräßlin]

On Monday 20 October 2014 15:41:41 Sebastian Kügler wrote:
> On Monday, October 20, 2014 15:35:55 Martin Gräßlin wrote:
> > On Monday 20 October 2014 14:58:19 Sebastian Kügler wrote:
> > > On Monday, October 20, 2014 14:30:50 Martin Gräßlin wrote:
> > > > On Monday 20 October 2014 14:13:33 Sebastian Kügler wrote:
> > > > 
> > > > 
> > > > please specify what you mean with "does nothing" and how you run
> > > > Weston
> > > > (on
> > > > a  VT or nested on X11).
> > > 
> > > The cursor doesn't move when running weston on its own VT. I don't see
> > > any
> > > visible reaction to the touchscreen at all.
> > 
> > ok, but the events work, right? If you tap a button it does something? To
> > me  it makes sense that the cursor doesn't move as the cursor belongs to
> > the pointer device and not to the touch device.
> 
> Ah, yes. Tapping works. I hadn't tried, assuming if it doesn't move the
> mouse cursor, tapping won't work either.

good, good. What I take from that is that in one way or another we need to 
provide visual feedback when using the touch screen.

Cheers
Martin

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

Re: Should touch events update the cursor position?

[Sebastian Kügler]

On Monday, October 20, 2014 15:35:55 Martin Gräßlin wrote:
> On Monday 20 October 2014 14:58:19 Sebastian Kügler wrote:
> > On Monday, October 20, 2014 14:30:50 Martin Gräßlin wrote:
> > > On Monday 20 October 2014 14:13:33 Sebastian Kügler wrote:
> > > 
> > >
> > > please specify what you mean with "does nothing" and how you run Weston
> > > (on
> > > a  VT or nested on X11).
> >
> > 
> >
> > The cursor doesn't move when running weston on its own VT. I don't see any
> > visible reaction to the touchscreen at all.
> 
> ok, but the events work, right? If you tap a button it does something? To
> me  it makes sense that the cursor doesn't move as the cursor belongs to
> the pointer device and not to the touch device.

Ah, yes. Tapping works. I hadn't tried, assuming if it doesn't move the mouse 
cursor, tapping won't work either.

> > When run under X11, the cursor moves and clicks seem to be interpreted.
> 
> I assume that the touch events on X11 are passed to Weston as pointer
> events  which makes it just a pointer and thus the cursor gets updated.

-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Should touch events update the cursor position?

[Martin Gräßlin]

On Monday 20 October 2014 14:58:19 Sebastian Kügler wrote:
> On Monday, October 20, 2014 14:30:50 Martin Gräßlin wrote:
> > On Monday 20 October 2014 14:13:33 Sebastian Kügler wrote:
> > > On Thursday, October 16, 2014 17:25:58 Martin Gräßlin wrote:
> > > > is that also the case on Wayland?
> > > 
> > > Under Weston, my touchscreen does nothing, that feels broken and is
> > > useless.
> > 
> > please specify what you mean with "does nothing" and how you run Weston
> > (on
> > a  VT or nested on X11).
> 
> The cursor doesn't move when running weston on its own VT. I don't see any
> visible reaction to the touchscreen at all.

ok, but the events work, right? If you tap a button it does something? To me 
it makes sense that the cursor doesn't move as the cursor belongs to the 
pointer device and not to the touch device.

> 
> When run under X11, the cursor moves and clicks seem to be interpreted.

I assume that the touch events on X11 are passed to Weston as pointer events 
which makes it just a pointer and thus the cursor gets updated.

Cheers
Martin

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

Re: Should touch events update the cursor position?

[Sebastian Kügler]

On Monday, October 20, 2014 14:35:40 Martin Gräßlin wrote:
> On Monday 20 October 2014 14:15:51 Sebastian Kügler wrote:
> > On Friday, October 17, 2014 07:26:55 Martin Gräßlin wrote:
> > > On Thursday 16 October 2014 16:32:02 Weng Xuetian wrote:
> > > 
> > > consider that the mouse could be moved at the same time as the touch
> > > events
> > > appear. This makes me very unsure about hiding the cursor.
> > >
> > > On Wayland they get dedicated touch events. Applications relying on
> > > having
> > > the  pointer position updated would clearly be an application bug.
> >
> > Or a feature.
> >
> > With forwarding touch events to mouse events, we can make a whole lot of
> > applications "just work" with touchscreens. I don't see why we should not
> > do that.
> 
> This is still inside the toolkit. It's not us who should send mouse events
> to  the toolkit. It's the toolkit's job to handle that correctly. My point
> still holds: if it's not properly forwarded it would be a toolkit bug
> instead of an application bug in that case.

OK, I think I misunderstood: I thought an application actually reacting to 
touchevents as mouse events and using them (for example for moving the cursor, 
clicks, drag and drop) would be a bug. To me, those things are features, 
without it my touchscreen would be useless.

> Anyway we cannot and shouldn't do something like sending mouse events for 
> touch events on Wayland. For X11 windows the situation is different, but on 
> Wayland that could end up nasty in having the toolkit process things twice.
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Should touch events update the cursor position?

[Sebastian Kügler]

On Monday, October 20, 2014 14:30:50 Martin Gräßlin wrote:
> On Monday 20 October 2014 14:13:33 Sebastian Kügler wrote:
> > On Thursday, October 16, 2014 17:25:58 Martin Gräßlin wrote:

> > > is that also the case on Wayland?
> >
> > Under Weston, my touchscreen does nothing, that feels broken and is
> > useless.
> please specify what you mean with "does nothing" and how you run Weston (on
> a  VT or nested on X11).

The cursor doesn't move when running weston on its own VT. I don't see any 
visible reaction to the touchscreen at all.

When run under X11, the cursor moves and clicks seem to be interpreted.
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 120624: add gtkbreeze, kconf_update tool to set gtk settings on first login

[Jonathan Riddell]

> On Oct. 17, 2014, 5:59 p.m., Andrew Lake wrote:
> > Sorry if it's too much trouble, but would you be able to do a screenshot 
> > showing a gtk app with these settings alongside a KF5 app?
> 
> Jonathan Riddell wrote:
> http://people.ubuntu.com/~jr/tmp/breeze-gtk2.png  GTK 2
> http://people.ubuntu.com/~jr/tmp/breeze-gtk3.png  GTK 3 (the demo app 
> uses client side windows but the window border is still shown, I'm told this 
> bug is fixed in newer GTK)
> http://people.ubuntu.com/~jr/tmp/breeze-qt4.png  Qt 4
> 
> Martin Gräßlin wrote:
> for GTK 3 it's important that the style doesn't set a shadow because 
> that's causing the strange effect you have in the screenshot.
> 
> Andrew Lake wrote:
> Just on the visual result, I think the proposal is quite reasonable. 
> There's a QtCurve Breeze settings file available in the breeze repo that 
> comes pretty close to matching the feel of the native Breeze style, but I'm 
> not aware of a QtCurve implementation in GTK3 (is there?). So I'm fine with 
> this solution to keeping GTK2/3 apps looking similar and not looking too out 
> of place when running in Plasma.

Right the QtCurve GTK3 port was abandoned because GTK3 removed useful themeing 
abilities


- Jonathan


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


On Oct. 19, 2014, 3:15 p.m., Jonathan Riddell wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120624/
> ---
> 
> (Updated Oct. 19, 2014, 3:15 p.m.)
> 
> 
> Review request for Plasma and Hugo Pereira Da Costa.
> 
> 
> Repository: breeze
> 
> 
> Description
> ---
> 
> add gtkbreeze, kconf_update tool to set gtk settings on first login
> this checks if gtk settings are already set, if they are not or are set to 
> oxygen they update them, else it quits
> it does this for both gtk 2 and 3
> it sets gtk to the orion theme because it's available for both gtk 2 and 3 
> and it looks similar to breeze
> it sets the icons to oxygen because I could not get breeze icons to work with 
> gtk 2 or 3
> I also could not get icons to show on buttons or in menus in gtk 3
> 
> 
> Diffs
> -
> 
>   misc/CMakeLists.txt ff891a9 
>   misc/gtkbreeze/CMakeLists.txt PRE-CREATION 
>   misc/gtkbreeze/gtkbreeze.upd PRE-CREATION 
>   misc/gtkbreeze/main.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/120624/diff/
> 
> 
> Testing
> ---
> 
> run it and run gtk-demo and gtk3-demo
> 
> 
> Thanks,
> 
> Jonathan Riddell
> 
>

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

Re: Re: Should touch events update the cursor position?

[Martin Gräßlin]

On Monday 20 October 2014 14:15:51 Sebastian Kügler wrote:
> On Friday, October 17, 2014 07:26:55 Martin Gräßlin wrote:
> > On Thursday 16 October 2014 16:32:02 Weng Xuetian wrote:
> > > If we're talking about the cursor image moving or not, the cursor will
> > > hide
> > > on other platform if touch event comes int. The cursor position doesn't
> > > matter if there's no visual feedback (hover event).
> > 
> > consider that the mouse could be moved at the same time as the touch
> > events
> > appear. This makes me very unsure about hiding the cursor.
> > 
> > > As for mouse.pos(), this should always be updated, for example there are
> > > application use mouse position to implement visual drag'n'drop.
> > 
> > On Wayland they get dedicated touch events. Applications relying on having
> > the  pointer position updated would clearly be an application bug.
> 
> Or a feature.
> 
> With forwarding touch events to mouse events, we can make a whole lot of
> applications "just work" with touchscreens. I don't see why we should not do
> that.

This is still inside the toolkit. It's not us who should send mouse events to 
the toolkit. It's the toolkit's job to handle that correctly. My point still 
holds: if it's not properly forwarded it would be a toolkit bug instead of an 
application bug in that case.

Anyway we cannot and shouldn't do something like sending mouse events for 
touch events on Wayland. For X11 windows the situation is different, but on 
Wayland that could end up nasty in having the toolkit process things twice.

Cheers
Martin

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

Re: Re: Should touch events update the cursor position?

[Martin Gräßlin]

On Monday 20 October 2014 14:13:33 Sebastian Kügler wrote:
> On Thursday, October 16, 2014 17:25:58 Martin Gräßlin wrote:
> > > > What do the people with a touch screen think about it? How do you
> > > > expect
> > > > it
> > > > to behave in a perfect world?
> > > 
> > > kinda used to touch events moving the cursor, so maybe is just habit..
> > > also, iirc in qt touchevents also generate qmouseevents iirc, so i think
> > > is
> > > expected the mouse pointer to behave accordingly  (or pretty much
> > > nothing
> > > would work on touch screens)
> > 
> > is that also the case on Wayland?
> 
> Under Weston, my touchscreen does nothing, that feels broken and is useless.

please specify what you mean with "does nothing" and how you run Weston (on a 
VT or nested on X11).

Cheers
Martin

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

Re: Should touch events update the cursor position?

[Sebastian Kügler]

On Friday, October 17, 2014 07:26:55 Martin Gräßlin wrote:
> On Thursday 16 October 2014 16:32:02 Weng Xuetian wrote:
> > If we're talking about the cursor image moving or not, the cursor will
> > hide
> > on other platform if touch event comes int. The cursor position doesn't
> > matter if there's no visual feedback (hover event).
> 
> consider that the mouse could be moved at the same time as the touch events 
> appear. This makes me very unsure about hiding the cursor.
> 
> > 
> >
> > As for mouse.pos(), this should always be updated, for example there are
> > application use mouse position to implement visual drag'n'drop.
> 
> On Wayland they get dedicated touch events. Applications relying on having
> the  pointer position updated would clearly be an application bug.

Or a feature.

With forwarding touch events to mouse events, we can make a whole lot of 
applications "just work" with touchscreens. I don't see why we should not do 
that.

Hiding the cursor, to me, is something cool, but extra.

Cheers,
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Should touch events update the cursor position?

[Sebastian Kügler]

On Thursday, October 16, 2014 17:25:58 Martin Gräßlin wrote:
> > > What do the people with a touch screen think about it? How do you expect
> > > it
> > > to behave in a perfect world?
> >
> > 
> >
> > kinda used to touch events moving the cursor, so maybe is just habit..
> > also, iirc in qt touchevents also generate qmouseevents iirc, so i think
> > is
> > expected the mouse pointer to behave accordingly  (or pretty much nothing
> > would work on touch screens)
> 
> is that also the case on Wayland?

Under Weston, my touchscreen does nothing, that feels broken and is useless.
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 120624: add gtkbreeze, kconf_update tool to set gtk settings on first login

[Sebastian Kügler]

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


Found a bunch of issues around string handling, error handling and compiler 
definitions.


misc/gtkbreeze/CMakeLists.txt


This (and a few other includes here) don't seem necessary. Could be cleaned 
up a tad.



misc/gtkbreeze/CMakeLists.txt


Is this really needed here? I think we can just make the code work with 
these flags set, and be happier about it.

Why did you add those?



misc/gtkbreeze/CMakeLists.txt


Might aswell just put main.cpp here and remove the additional temporary var 
gtkbreeze_SRCS. It's only one source file, anyway.



misc/gtkbreeze/main.cpp


foreach (

missing space



misc/gtkbreeze/main.cpp


"/" should be a QDir::Separator, this will make it much faster since it can 
skip the more expensive QString ctor. Also, inconsistent spacing on that line.



misc/gtkbreeze/main.cpp


QDir::separator() instead of "/"



misc/gtkbreeze/main.cpp


QStringLiteral("oxygen-gtk") is faster



misc/gtkbreeze/main.cpp


exists (grammar)



misc/gtkbreeze/main.cpp


Use QStringLiteral here and on the following line for faster string creation



misc/gtkbreeze/main.cpp


no spacing inside parentheses



misc/gtkbreeze/main.cpp


Error handling when opening the file fails?



misc/gtkbreeze/main.cpp


Wrapping all the strings on this and the following lines in QStringLiterals 
will make creation of all those strings much faster. (And removes the need for 
non-standard compiler flags.)



misc/gtkbreeze/main.cpp


Superfluous, the QFile object goes out of scope here anyway, and will be 
closed in the dtor.



misc/gtkbreeze/main.cpp


const



misc/gtkbreeze/main.cpp


const



misc/gtkbreeze/main.cpp


const



misc/gtkbreeze/main.cpp


I don't understand this. Does our startkde set the Ubuntu font? (I'm pretty 
sure that it's not.)

Can you clarify, or perhaps explain how the Oxygen font is set here?



misc/gtkbreeze/main.cpp


Error handling here could be improved. I don't now exactly what makes sense 
here (return !0 if no settings have changed, if settings files aren't writable, 
perhaps?).


- Sebastian Kügler


On Oct. 19, 2014, 3:15 p.m., Jonathan Riddell wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120624/
> ---
> 
> (Updated Oct. 19, 2014, 3:15 p.m.)
> 
> 
> Review request for Plasma and Hugo Pereira Da Costa.
> 
> 
> Repository: breeze
> 
> 
> Description
> ---
> 
> add gtkbreeze, kconf_update tool to set gtk settings on first login
> this checks if gtk settings are already set, if they are not or are set to 
> oxygen they update them, else it quits
> it does this for both gtk 2 and 3
> it sets gtk to the orion theme because it's available for both gtk 2 and 3 
> and it looks similar to breeze
> it sets the icons to oxygen because I could not get breeze icons to work with 
> gtk 2 or 3
> I also could not get icons to show on buttons or in menus in gtk 3
> 
> 
> Diffs
> -
> 
>   misc/CMakeLists.txt ff891a9 
>   misc/gtkbreeze/CMakeLists.txt PRE-CREATION 
>   misc/gtkbreeze/gtkbreeze.upd PRE-CREATION 
>   misc/gtkbreeze/main.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/120624/diff/
> 
> 
> Testing
> ---
> 
> run it and run gtk-demo and gtk3-demo
> 
> 
> Thanks,
> 
> Jonathan Riddell
> 
>

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

[Breeze] [Bug 338979] Breeze window decoration adds spacing around the windeco

[Aleix Pol]

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

Aleix Pol  changed:

   What|Removed |Added

 CC||aleix...@kde.org

--- Comment #7 from Aleix Pol  ---
I can confirm I have this behavior too.

-- 
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 120623: LocationRunner: Convert case insensitive path to a proper one

[David Edmundson]

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



runners/locations/locationrunner.cpp


actually, can you make this

foundMatch = dir.cd(entry);

this way you catch errors on non-executable folders.


- David Edmundson


On Oct. 20, 2014, 10:16 a.m., Vishesh Handa wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120623/
> ---
> 
> (Updated Oct. 20, 2014, 10:16 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Bugs: 95
> https://bugs.kde.org/show_bug.cgi?id=95
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> See bug report
> 
> 
> Diffs
> -
> 
>   runners/locations/locationrunner.cpp 13035a9 
> 
> Diff: https://git.reviewboard.kde.org/r/120623/diff/
> 
> 
> Testing
> ---
> 
> Bug fixed.
> 
> 
> Thanks,
> 
> Vishesh Handa
> 
>

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

Re: Review Request 120623: LocationRunner: Convert case insensitive path to a proper one

[David Edmundson]

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

Ship it!



runners/locations/locationrunner.cpp


The code handles the last entry being a folder as well as a file but this 
comment ends up being more confusing than it helps.


- David Edmundson


On Oct. 20, 2014, 10:16 a.m., Vishesh Handa wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120623/
> ---
> 
> (Updated Oct. 20, 2014, 10:16 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Bugs: 95
> https://bugs.kde.org/show_bug.cgi?id=95
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> See bug report
> 
> 
> Diffs
> -
> 
>   runners/locations/locationrunner.cpp 13035a9 
> 
> Diff: https://git.reviewboard.kde.org/r/120623/diff/
> 
> 
> Testing
> ---
> 
> Bug fixed.
> 
> 
> Thanks,
> 
> Vishesh Handa
> 
>

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

Minutes Monday Plasma Hangout

[Sebastian Kügler]

Minutes Plasma Hangout, 20-10-2014

Present: Marco, Martin G, Sebastian, Aleix, David, Martin K, Jonathan, Vishesh


Aleix:
- Fixed bug in panel placement with multiscreen
- Worked on a Muon notifier Plasmoid

David:
- Fixed SDDM integration problems for the ISO
- Fixed SDDM focus bug
- Released telepath 0.9.0

Jonathan:
- Released Plasma 5.1, well received
- Had release party with belly dancers
- Worked on fixing GTK theming settings, some integration pains remain (CSD)
- Do we need a kickoff meeting for 5.2? Will send a doodle around

Marco
- Worked on bugfixes (panel related)
- Review for a bug in Qt, please look at 
https://codereview.qt-project.org/#/c/97050/
- Investigates a bug in panel plasmoid alignment and input areas

Martin G:
- Wayland work, especially
- preparing work to support libinput directly
- implemented subcompositor and subsurface interfaces for client and server in 
KWayland

Martin K:
- Investigating a bug with Chome creating lots of statusnotifiers
- WOrking on porting KAccounts and friends

Vishesh:
- API changes in Baloo master, preparing to make it stable enough for 
Frameworks
- Trying

Sebastian:
- Helped with release promo
- Worked on libkscreen\wayland, kcmshell5 kcm_kscreen starts up now
- Will run Marco through the pluginloader indexing


-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 120623: LocationRunner: Convert case insensitive path to a proper one

[Vishesh Handa]

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

(Updated Oct. 20, 2014, 10:16 a.m.)


Review request for Plasma.


Changes
---

Added more checks.


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


Repository: plasma-workspace


Description
---

See bug report


Diffs (updated)
-

  runners/locations/locationrunner.cpp 13035a9 

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


Testing
---

Bug fixed.


Thanks,

Vishesh Handa

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

Re: The usage statistics [kactivities, baloo, ktp, plasma]

[David Edmundson]

On Mon, Oct 13, 2014 at 6:59 PM, Ivan Čukić  wrote:

> Hi all,
>
> As promised, starting a discussion on how we can use the usage statistics
> gathered by kactivitymanagerd (kamd in the rest of the text). And the
> design
> of the API to cover the use-cases.
>
> The point is to discuss all of this and put the summaries on the etherpad
> page
> at https://notes.kde.org/p/KActivities_Usage_Statistics
>
>
> 1. Use-cases
> =
>
> The main ideas I had while developing Lancelot (some overlap with those
> that
> Eike and David have):
>
>  - Automatically deduced favourite applications for the users that didn't
> set
> them up (not important whether they actually end up in the favourites
> section,
> or are used just for sorting in krunner or something).
>  - The same as the above, but for documents (per-application, and global)
> or
> contacts or ...

 - Replacing the 'recent documents' with something more meaningful (kinda a
> subset of the previous item)
>  - Tasks applet and launchers could show the list of important (or recent)
> documents opened in a specific application.
>

One use case that we might want to consider is including email frequency
when sorting contacts.

What makes this very different from the rest is that the length of event
doesn't really apply. I tend to write an email then fill in the address
last, so kmail couldn't give accurate stats if it tried. and the length of
time I spent typing might not have any impact.

I'm a bit skeptical of the time tracking rather than usage tracking in
general, if a user opens something 10 times and closes that quickly, it's
more important to list that in favourites than something a user only opens
once and leaves open. We might need to have an API that doesn't pass a wID
and just inserts an arbitrary time and/or a way to not put any weight on
the time interval in the querying API.


>  - ** more advanced ** Deducing which things belong to each other based on
> the
> fact they have been often used together and similar.
>
>



>
> 2. What is currently there
> =
>
> (mostly copied from the mail I sent Eike some time ago)
>
> - It supports tracking for open/close, focus-in/out, modified and accessed
> events (from the API side, handled by KActivities::ResourceInstance class
> in a
> pretty RAII manner :) )
> - Every event has the activity in which it occurred (usedActivity field),
> application that triggered the event (initiatingAgent) and the timestamps
> (and
> the URL of the thing - targettedResource - a document, a contact, ...). The
> names are a bit cumbersome, they are taken from the ontology that was
> designed
> for this purpose. You can write Agent, Activity, Resource for the sake of
> brevity.
> - Apart from that, it also keeps the scores for the things.
>
> Vishesh asked for the formula for the scoring - see appendix 1.
>
> Applications that supported this in 4.x were (I'm probably missing a few):
> Dolphin, Gwenview, Calligra (modulo Kexi), Okular, Kate, KWrite and Vim in
> konsole. I have no idea whether the patches remained in Qt5 ports.
>
> Gwenview code remained. Though it's purely logging and not using any of it.


>
> 3. What will be needed
> 
>
> Integration with baloo. It will require patches on both sides if we are to
> support all the use-cases without cross-queries. We will need accessible
> file
> types via sqlite (on baloo side) and baloo identifiers or something on kamd
> side.
>
> One of the things that I think will be needed is some kind of additional
> payload that the applications will be able to store alongside the resource
> event. We'll see after we collect the use-cases.
>
>
> 4. Reading API
> ===
>
> This needs to be designed. I would not be surprised if the API ends up
> being
> similar to baloo's querying system since it seems we will have quite a
> diverse
> set of use-cases. Although, it should provide a proper live data model for
> the
> results.
>
>
> Appendix 1: Formula for the resource scoring:
> ===


> LaTeX formatted:
> S = \sum _{i = 1} ^ n
> e^{-d_i} e^{k_i \log(l_i)}
>
> Haskell-like formatted, whichever you find easier to read :)
> sum [
> exp (-di) * exp ( ki * log li ) | i <- [1..n]
> ]
>
> where d_i is the time that passed since the i-th event, k_i coefficient
> depending on the type of the event, l_i length of the event (time distance
> between open and close for example, or focus in and out)
>
It can be rewritten to look prettier (exp log = id and so on), but this
> conveys the meaning in a nicer way by separating the terms according to
> their
> meaning.
>
>

> The main ideas behind the formula are:
>  - score degrades with the time, so if a document was kept open in okular
> for
> an hour yesterday, it will have a significantly higher score than a
> document
> that was kept open for a whole day a year ago;
>  - different events have different meanings;
>  - event time interval is measured on a loga

[Breeze] [Bug 340147] New: Folder icon is black on black with Breeze-dark plasma theme

[Domenico Camasta]

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

Bug ID: 340147
   Summary: Folder icon is black on black with Breeze-dark plasma
theme
   Product: Breeze
   Version: 5.1.0
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: plasma-devel@kde.org
  Reporter: domenico.cama...@gmail.com

Created attachment 89207
  --> https://bugs.kde.org/attachment.cgi?id=89207&action=edit
black icon over black background in krunner

See the attached picture. The folder icon is barely visible. The complete setup
is:

breeze-dark plasma theme
breeze widget style
breeze color scheme

-- 
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 120577: Remove shutdown option from lockscreen's look and feel

[David Edmundson]

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


+1. and +1 for putting in 5.1 too.

I don't really agree with you on the suspend discussion but it's clear we're 
not going anywhere on that soon and it shouldn't hold up removing shutdown 
which I think we do all agree on.

- David Edmundson


On Oct. 20, 2014, 5:59 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120577/
> ---
> 
> (Updated Oct. 20, 2014, 5:59 a.m.)
> 
> 
> Review request for Plasma and Aleix Pol Gonzalez.
> 
> 
> Bugs: 339453
> https://bugs.kde.org/show_bug.cgi?id=339453
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Logging out from the locked screen is impossible. Logging out means
> interaction with the session due to the session manager. The session
> manager asks all applications to quit and applications are allowed to
> ask for example saving changes. The session manager stopps the
> logout in this case and asks the window manager to focus this window
> and the session manager will only continue the logout once the
> application resolved the situation. At any time in this process the
> user is still able to abort the logout!
> 
> Switching to the application which needs interaction is impossible,
> though as the screen is still locked. The result is a seemingly
> frozen system as the logout cannot continue and there is no indication
> what is going on.
> 
> Of course the lock screen cannot unlock the session for the logout as
> that would circumvent the security. If the lock screen would unlock
> one would just have to click the button and abort the logout really
> fast to have the system unlocked. So this is clearly not an option.
> 
> The result is: we cannot implement this functionality in a working
> and secure manner, so it's better to remove it.
> 
> 
> Diffs
> -
> 
>   ksmserver/screenlocker/greeter/greeterapp.cpp 
> fd1d20b824dd7781cb5c2e96895694f290a46877 
>   lookandfeel/contents/lockscreen/LockScreen.qml 
> 7d730cf1ebd8241dfe1c00a2bef86ec4a3f0212d 
>   ksmserver/screenlocker/greeter/greeterapp.h 
> f3033c701fb3c3ce5fa8f12f58ee8c6af739444b 
> 
> Diff: https://git.reviewboard.kde.org/r/120577/diff/
> 
> 
> Testing
> ---
> 
> run kscreenlocker_greeter --testing and locked the screen - button is gone.
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

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