Review Request 120577: Remove shutdown option from lockscreen's look and feel

[Martin Gräßlin]

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

Review request for Plasma and Aleix Pol Gonzalez.


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
-

  lookandfeel/contents/lockscreen/LockScreen.qml 
7d730cf1ebd8241dfe1c00a2bef86ec4a3f0212d 

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

Re: Re: wallpapers on lock screen

[Martin Gräßlin]

On Monday 13 October 2014 22:47:10 ctoenn...@interstel.de wrote:
> On 13.10.2014 17:21, Martin Gräßlin wrote:
> > On Monday 13 October 2014 16:44:30 Martin Klapetek wrote:
> >> I think by default it should use the (current visible) desktop wallpaper
> >> in
> >> the lockscreen.
> > 
> > for privacy reasons the current configured wallpaper should not be used in
> > the lock screen (or splash screen or whatever).
> > 
> > Having a checkbox "also use on lock screen" sounds like a good solution,
> > though.
> 
> What happens if this is unchecked?

if we go for this solution it would be the default wallpaper otherwise.

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: Review Request 120471: Add Registry::sync() signal

[Martin Gräßlin]

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

Ship it!


looks good

- Martin Gräßlin


On Oct. 14, 2014, 4:17 a.m., Sebastian Kügler wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120471/
> ---
> 
> (Updated Oct. 14, 2014, 4:17 a.m.)
> 
> 
> Review request for kwin, Plasma and Martin Gräßlin.
> 
> 
> Repository: kwayland
> 
> 
> Description
> ---
> 
> Add Registry::sync() signal
> 
> Emitted when the Wayland display is done flushing the initial interface
> callbacks, announcing wl_display properties. This can be used to compress
> events. Note that this signal is emitted only after announcing interfaces,
> such as outputs, but not after receiving callbacks of interface properties,
> such as the output's geometry, modes, etc..
> This signal is emitted from the wl_display_sync callback.
> 
> For this, we add a wl_callback_listener to the registry's Private,
> enqueue its events properly, if necessary, and trigger the signal
> through a callback mechanism similar to the wl_registry callbacks.
> 
> This signal allows users of the API to find out when the signal
> emissions, such as outputAnnounced, etc. for all currently existing
> interfaces is complete.
> 
> 
> Diffs
> -
> 
>   autotests/client/test_wayland_registry.cpp 571be0f 
>   src/client/registry.h 9e63a2b 
>   src/client/registry.cpp 207cdef 
> 
> Diff: https://git.reviewboard.kde.org/r/120471/diff/
> 
> 
> Testing
> ---
> 
> tests in libkscreen exercise this feature, it works as expected, meaning I 
> can notify when all initial synchronization is done.
> 
> 
> Thanks,
> 
> Sebastian Kügler
> 
>

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

Re: Review Request 120471: Add Registry::sync() signal

[Sebastian Kügler]

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

(Updated Oct. 14, 2014, 2:17 a.m.)


Review request for kwin, Plasma and Martin Gräßlin.


Changes
---

* Use WaylandPointer to store and manage lifecycle of wl_callback
* If a callback is underway, also add it to the proper queue in setEventQueue()
* Clean up the test's object lifecycle so it doesn't get in the way of 
following tests

I'm getting a spurious failure in testWaylandOutput when run from make test, 
but never when running 
the test binary individually, I don't know if this is related.

WaylandPointer is a nice and handy tool.


Repository: kwayland


Description
---

Add Registry::sync() signal

Emitted when the Wayland display is done flushing the initial interface
callbacks, announcing wl_display properties. This can be used to compress
events. Note that this signal is emitted only after announcing interfaces,
such as outputs, but not after receiving callbacks of interface properties,
such as the output's geometry, modes, etc..
This signal is emitted from the wl_display_sync callback.

For this, we add a wl_callback_listener to the registry's Private,
enqueue its events properly, if necessary, and trigger the signal
through a callback mechanism similar to the wl_registry callbacks.

This signal allows users of the API to find out when the signal
emissions, such as outputAnnounced, etc. for all currently existing
interfaces is complete.


Diffs (updated)
-

  autotests/client/test_wayland_registry.cpp 571be0f 
  src/client/registry.h 9e63a2b 
  src/client/registry.cpp 207cdef 

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


Testing
---

tests in libkscreen exercise this feature, it works as expected, meaning I can 
notify when all initial synchronization is done.


Thanks,

Sebastian Kügler

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

Re: Review Request 120550: Use the same strategy as FrameSvgItem and IconItem in QIconItem

[Aleix Pol Gonzalez]

> On Oct. 13, 2014, 1:35 p.m., Marco Martin wrote:
> > src/quickaddons/managedtexturenode.h, line 52
> > 
> >
> > even if will always remain just this member, just to me sure, it should 
> > be in a dpointer
> 
> Aleix Pol Gonzalez wrote:
> I don't think it's a good idea to add a d-pointer there. It's a class to 
> encapsulate the object, I don't see why we should store more things in there.
> 
> If needs changed, then I'd suggest to create another class.
> 
> Marco Martin wrote:
> if it's exported, i prefer a dpointer anyways

Can we please discuss this? I really don't think we want to be so cheap when it 
comes to memory usage. This means that each node in the scene will take a 
payload for no much reason.


- Aleix


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


On Oct. 13, 2014, 5:54 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120550/
> ---
> 
> (Updated Oct. 13, 2014, 5:54 p.m.)
> 
> 
> Review request for KDE Frameworks, Plasma, David Edmundson, and Marco Martin.
> 
> 
> Repository: kdeclarative
> 
> 
> Description
> ---
> 
> Moves the caching types used in Plasma Workspace into a QuickAddons submodule.
> 
> Adopts them in QIconItem by moving it from a QPainterItem to a QQuickPainter 
> item. Uses the same strategies used in Plasma Framework for caching the 
> textures.
> 
> 
> Diffs
> -
> 
>   src/qmlcontrols/kquickcontrolsaddons/CMakeLists.txt 2977812 
>   src/qmlcontrols/kquickcontrolsaddons/qiconitem.h 839a33f 
>   src/qmlcontrols/kquickcontrolsaddons/qiconitem.cpp 0eb46b1 
>   src/quickaddons/CMakeLists.txt PRE-CREATION 
>   src/quickaddons/imagetexturescache.h PRE-CREATION 
>   src/quickaddons/imagetexturescache.cpp PRE-CREATION 
>   src/quickaddons/managedtexturenode.h PRE-CREATION 
>   src/quickaddons/managedtexturenode.cpp PRE-CREATION 
>   tests/qiconitem_test.qml PRE-CREATION 
>   src/CMakeLists.txt eb0dfd3 
> 
> Diff: https://git.reviewboard.kde.org/r/120550/diff/
> 
> 
> Testing
> ---
> 
> I added some manual test (that was impossible to run before the patch). Also 
> tested it in KRunner and Muon Discover, which use the component. Everything 
> still works.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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

Re: wallpapers on lock screen

[David Edmundson]

On Mon, Oct 13, 2014 at 4:09 PM, Marco Martin  wrote:

> Hi all,
>
> this is already 5.2 stuff, but just to discuss.
> we still have one burned-in fixed wallpaper for the lock screen, so at this
> point it should get a bit of attention.
>
> one thing i'm not sure to do if i want to have again the possibility to put
> widgets in the lock screen as it was in kde4. there may be interests on it,
> but on the other hand i am not seeing much complaints that at the moment is
> missing.
>

Personally I think what the VDG designed ends up looking a lot better than
letting users drag some clocks and some post-it notes across the desktop.

Changing what is shown is currently is do-able with look and feel packages,
I don't think we need to create a second implementation in addition to
that.


> on either case, should be very easy to recycle the complete wallpaper
> mechanism of plasmashell, even the qml only wallpapers (that if animated..
> yay, screensavers!)
>


I'd quite like to use the wallpaper plugins from SDDM too; which means
exposing WallpaperInterface in a slightly different manner than you'd
probably be wanting to use for the lock screen, as I can't go via a
Containment.



> just to see what path to take do design and implement correctly, if just
> boring wallpapers or full widgets.
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: wallpapers on lock screen

[Eike Hein]

On 13.10.2014 22:50, ctoenn...@interstel.de wrote:

Why not simply have the checkbox "use default wallpaper" in the
lockscreen kcm?
Unchecked, it would allow for picking a background yourself.


I think we're kind of, of sort of discussing three different
things at the same time:

a) The ability to have the user's current desktop background
in the lock screen.

Notes on that:
- If it's supposed to be generic (i.e. works with all wallpaper
  type plugins), it's difficult to establish sync.
- Dumping the actually rendered wallpaper into a file and
  showing it in the lock screen could be one way to go, but
  hard because of display hotplug.
- Dumping also means no animated wallpapers on the lock screen.
- If instead we only want to support it for Image wallpapers,
  the config logically has to be part of that plugin, otherwise
  things get messy (e.g. if the option to use the wallpaper is
  in the lock screen config, it makes no sense if the wallpaper
  plugin isn't Image - so you'd have to read configs across
  products to make it conditional, and the user would have low
  insight into what's going on).

b) Whether doing 'a' *by default* is a good idea or not.

Notes on that:
- Thumbs down from me for the privacy/securty angle.
- Blurring the wallpaper heavily mitigates this to some
  degree. It still makes my spider sense tingle, but I
  could maybe sleep at night. :P

c) The option to set a custom wallpaper for the lock screen.

This is in some sense entirely independent of the above. I
think we want to allow this in principle; the difficulty is
in UI design - if 'a' requires us to stick a "Also use on
lock screen" into the Image plugin's wallpaper config it
fighrs with a wallpaper picker in the Lock Screen KCM, and
there's also the issue of having the former in the wall-
paper config in cases where the lock screen design from the
look and feel package doesn't care about backgrounds.

Further, wallpapers are per-activity, ...

This is one of these situations where suporting all the
different features we have in concert ends up being diffi-
cult. There's some radical solutions:

- Give up on 'a' and 'b' entirely and just do 'c'.
- Throw out all wallpaper plugins except Image.

This is why $competitor sometimes gets blamed for having
too few features, but has few features for a reason - it's
easy to lock yourself into sudoku puzzles with many features.



Greetings, Clemens.


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

Re: wallpapers on lock screen

[ctoenn...@interstel.de]

On 13.10.2014 17:21, Eike Hein wrote:



On 13.10.2014 17:19, Marco Martin wrote:
not really, just the lockscreen view would load the qml files used 
for system
wallpapers now, and then they should just "automagically work" by 
default
would just be the image wallpaper that by default uses the image 
specified in

the plasma theme, so would still be l&f package dependent


And what if the user uses a slide show with a couple of custom
pictures? You'd need to both sync that config *and* what image
it's currently on, if the idea here is a smooth visual transi-
tion without perceived glitches.

And if not ... why add a hack that only works in a constrained
scenario instead of across the customization options we actually
have?


Why not simply have the checkbox "use default wallpaper" in the 
lockscreen kcm?

Unchecked, it would allow for picking a background yourself.

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

Re: Fwd: Plasma Framework problems

[šumski]

On Monday 13 of October 2014 13:07:35 Marco Martin wrote:
> On Sunday 12 October 2014, David Edmundson wrote:
> > On 12 Oct 2014 18:04, "šumski"  wrote:
> > > On Sunday 12 of October 2014 11:58:44 David Edmundson wrote:
> > > > > I'll report back when I've confirmed this and then we can work out
> > 
> > how we
> > 
> > > > > proceed.
> > > > > 
> > > > > Reverting a3932843386a29faa3c62bf2934a173a3781d56c does indeed make
> > > > 
> > > > everything work.
> > > > 
> > > > Assuming we don't have a time machine our options are:
> > > >  - revert this commit and release plasma-framework 5.3.1 really
> > > >  quickly
> > > 
> > > Please go with this option...
> > 
> > I need approval from Marco and other David.
> 
> after a quick chat with David E this morning, I would revert that patch
> (and then remove the plugin in plasma-workspace master)
> *but* this only if there will be a 5.3.1 (there should be a fix in
> kwindowsystem as well as far i understood, so would be good a 5.3.1 release
> with both fixes)

this sounds like a good plan (though i don't know if reverting in plasma-
workspace is needed, and why only master, 5.1.0 is not out yet)
though kwindowsystem is uploaded 2 days ago to 5.3.0 dir


Cheers,
Hrvoje


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: wallpapers on lock screen

[ctoenn...@interstel.de]

On 13.10.2014 17:21, Martin Gräßlin wrote:

On Monday 13 October 2014 16:44:30 Martin Klapetek wrote:

I think by default it should use the (current visible) desktop wallpaper in
the lockscreen.

for privacy reasons the current configured wallpaper should not be used in the
lock screen (or splash screen or whatever).

Having a checkbox "also use on lock screen" sounds like a good solution,
though.


What happens if this is unchecked?

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

Re: 5.1 Errata

[Andrew Lake]

Can anyone confirm that this bug exists in 5.1? I don't think the fix made
it in time, but I wanted to check before adding it to the errata.

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

Thanks much,
Andrew

On Mon, Oct 13, 2014 at 3:54 AM, Jonathan Riddell  wrote:

> As discussed at hangout, if you know of bugs which users should be aware
> of please add them to
>
> https://community.kde.org/Plasma/5.1_Errata
>
> Jonathan
>
>
> ___
> 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

[Powerdevil] [Bug 339391] system hangs during suspend-to-ram (must poweroff), while pm-suspend works.

[Vincent Petry]

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

--- Comment #15 from Vincent Petry  ---
Good to know.
I have now set pm_trace to 1 to hopefully capture more info from the next
crash, if it happens.

See https://wiki.ubuntu.com/DebuggingKernelSuspend

-- 
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 339391] system hangs during suspend-to-ram (must poweroff), while pm-suspend works.

[Roberto]

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

--- Comment #14 from Roberto  ---
In my case the pm-suspend log is the  same when it works and when it doesn't: 
pm-suspend always finishes the procedure without errors or crashes, but
sometimes at the end the system hangs instead of actually suspend (or
shutdown).

-- 
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: Plasma 5.1.0

[Albert Astals Cid]

El Dilluns, 13 d'octubre de 2014, a les 11:01:49, Sebastian Kügler va 
escriure:
> On Thursday, October 09, 2014 21:36:58 Albert Astals Cid wrote:
> > El Dijous, 9 d'octubre de 2014, a les 14:26:48, Jonathan Riddell va
> 
> escriure:
> > > Plasma 5.1.0 tars up now at
> > > 
> > >  http://starsky.19inch.net/~jr/tmp/plasma-5.1.0/
> > > 
> > > and coming soon to depot
> > > 
> > > 
> > > 
> > > sha256 sums at
> > > 
> > >  https://www.kde.org/info/source-plasma-5.1.0.inc
> > > 
> > > Release due on Tuesday.
> > 
> > 4.14.2 release is also on Tueday, maybe i should move it to wednesday?
> 
> I think that would make sense. I'm prepping the Plasma 5.1.0 release notes
> now. If need be, we can also push that one one day forward.

Ok, let's move 4.14.2 to wednesday then.

Cheers,
  Albert

> 
> Cheers,

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

Re: Review Request 120550: Use the same strategy as FrameSvgItem and IconItem in QIconItem

[Marco Martin]

> On Oct. 13, 2014, 1:35 p.m., Marco Martin wrote:
> > src/quickaddons/managedtexturenode.h, line 52
> > 
> >
> > even if will always remain just this member, just to me sure, it should 
> > be in a dpointer
> 
> Aleix Pol Gonzalez wrote:
> I don't think it's a good idea to add a d-pointer there. It's a class to 
> encapsulate the object, I don't see why we should store more things in there.
> 
> If needs changed, then I'd suggest to create another class.

if it's exported, i prefer a dpointer anyways


- Marco


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


On Oct. 13, 2014, 5:54 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120550/
> ---
> 
> (Updated Oct. 13, 2014, 5:54 p.m.)
> 
> 
> Review request for KDE Frameworks, Plasma, David Edmundson, and Marco Martin.
> 
> 
> Repository: kdeclarative
> 
> 
> Description
> ---
> 
> Moves the caching types used in Plasma Workspace into a QuickAddons submodule.
> 
> Adopts them in QIconItem by moving it from a QPainterItem to a QQuickPainter 
> item. Uses the same strategies used in Plasma Framework for caching the 
> textures.
> 
> 
> Diffs
> -
> 
>   src/qmlcontrols/kquickcontrolsaddons/CMakeLists.txt 2977812 
>   src/qmlcontrols/kquickcontrolsaddons/qiconitem.h 839a33f 
>   src/qmlcontrols/kquickcontrolsaddons/qiconitem.cpp 0eb46b1 
>   src/quickaddons/CMakeLists.txt PRE-CREATION 
>   src/quickaddons/imagetexturescache.h PRE-CREATION 
>   src/quickaddons/imagetexturescache.cpp PRE-CREATION 
>   src/quickaddons/managedtexturenode.h PRE-CREATION 
>   src/quickaddons/managedtexturenode.cpp PRE-CREATION 
>   tests/qiconitem_test.qml PRE-CREATION 
>   src/CMakeLists.txt eb0dfd3 
> 
> Diff: https://git.reviewboard.kde.org/r/120550/diff/
> 
> 
> Testing
> ---
> 
> I added some manual test (that was impossible to run before the patch). Also 
> tested it in KRunner and Muon Discover, which use the component. Everything 
> still works.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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

[Powerdevil] [Bug 339391] system hangs during suspend-to-ram (must poweroff), while pm-suspend works.

[Vincent Petry]

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

--- Comment #13 from Vincent Petry  ---
I've now started the following:
- skype
- kopete: connected
- apache 2
- mysql
- thunderbird

Talk about murphy's law or heisenbug... suspend to ram now still works
properly.
I'm pretty sure it will hang again when I least expect it.

Roberto, if you managed to hang it again, can you post pm-suspend.log ?
I'll do the same as soon as I can reproduce the issue again, as you say maybe
it will happen after a few hours.

You mentioned that in your case pm-suspend also crashed once, so it is likely
that the problem is on the kernel side.

Please let me know whether you also had some of the apps I mentioned above
loaded (including vboxdrv), in case it's all related.

-- 
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 339391] system hangs during suspend-to-ram (must poweroff), while pm-suspend works.

[Roberto]

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

--- Comment #12 from Roberto  ---
Vincent:  let the PC with power on for one hour or more, and then try
pm-suspend

-- 
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 339391] system hangs during suspend-to-ram (must poweroff), while pm-suspend works.

[Vincent Petry]

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

--- Comment #11 from Vincent Petry  ---
Hmmm... suspend to ram worked now from KDE.
Here is the list of programs I have opened, for reference:
- kopete: disconnected
- wifi
- owncloud sync client
- kmail
- konsole

And in case it matters, I have the vboxdrv module loaded at all times.
Also note: I have enabled the swap partition, but it didn't prevent it to
crash.
My filesystem is btrfs.

-- 
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 339391] system hangs during suspend-to-ram (must poweroff), while pm-suspend works.

[Vincent Petry]

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

--- Comment #10 from Vincent Petry  ---
Created attachment 89117
  --> https://bugs.kde.org/attachment.cgi?id=89117&action=edit
Successful pm-suspend log

Tried pm-suspend three times and it worked fine.
See attached log.

Next up: make it crash then get the log.

-- 
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 120550: Use the same strategy as FrameSvgItem and IconItem in QIconItem

[Aleix Pol Gonzalez]

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

(Updated Oct. 13, 2014, 5:54 p.m.)


Review request for KDE Frameworks, Plasma, David Edmundson, and Marco Martin.


Repository: kdeclarative


Description
---

Moves the caching types used in Plasma Workspace into a QuickAddons submodule.

Adopts them in QIconItem by moving it from a QPainterItem to a QQuickPainter 
item. Uses the same strategies used in Plasma Framework for caching the 
textures.


Diffs
-

  src/qmlcontrols/kquickcontrolsaddons/CMakeLists.txt 2977812 
  src/qmlcontrols/kquickcontrolsaddons/qiconitem.h 839a33f 
  src/qmlcontrols/kquickcontrolsaddons/qiconitem.cpp 0eb46b1 
  src/quickaddons/CMakeLists.txt PRE-CREATION 
  src/quickaddons/imagetexturescache.h PRE-CREATION 
  src/quickaddons/imagetexturescache.cpp PRE-CREATION 
  src/quickaddons/managedtexturenode.h PRE-CREATION 
  src/quickaddons/managedtexturenode.cpp PRE-CREATION 
  tests/qiconitem_test.qml PRE-CREATION 
  src/CMakeLists.txt eb0dfd3 

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


Testing
---

I added some manual test (that was impossible to run before the patch). Also 
tested it in KRunner and Muon Discover, which use the component. Everything 
still works.


Thanks,

Aleix Pol Gonzalez

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

[Powerdevil] [Bug 339391] system hangs during suspend-to-ram (must poweroff), while pm-suspend works.

[Vincent Petry]

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

--- Comment #9 from Vincent Petry  ---
The version on which it worked was openSUSE 13.1 x86_64 with KDE 4-4.11.5 and
kernel 3.11.10-21-desktop.

And it's now broken on openSUSE Factory x86_64 with KDE 4.14.1-1.2 and kernel
3.16.4-1.g7a8842b-desktop

I'll do some tests and post results.

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

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

[Ivan Čukić]

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


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


-- 
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: wallpapers on lock screen

[Eike Hein]

On 13.10.2014 17:48, Martin Gräßlin wrote:

please keep in mind that screens might get added while the screen is locked.


Right, so plasmashell would have to initialize it, dump the wallpaper
and get it to the lockscreen.



Cheers
Martin


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

Re: wallpapers on lock screen

[Harald Sitter]

On Mon, Oct 13, 2014 at 6:06 PM, Jens Reuterberg  wrote:
> 1) It didn't reveal the nature of your wallpaper (we tested,
> extensively)

knock yourselves out guessing :P
http://imgur.com/a/1bHH5

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

Re: wallpapers on lock screen

[Jens Reuterberg]

Sry for a late reply (sick and been sleeping) but the one 
Harald Sitter and I fiddled with during Akademy was kinda 
nice where it used a blurred version of your wallpaper.

1) It didn't reveal the nature of your wallpaper (we tested, 
extensively)
2) It creates the sensation of "fading to desktop" when 
unlocked.

If it IS somehow a security issue I don't know but it was 
way cooler than having a random wallpaper set by 
default which made the login process from a lock screen 
feel jerky and out of phase.

On Monday 13 October 2014 17.11.20 Marco Martin wrote:
> On Monday 13 October 2014, Eike Hein wrote:
> > Still, adding the functionality to pick up the current or a
> > custom wallpaper is fine if done correctly, of course, 
but not
> > as a default IMHO.
> 
> instead of some automagic and default i was more 
thinking about some option
> in the ordinary wallpaper settings "use this in the 
lockscreen" maybe
> unchecked by default

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

Re: Re: wallpapers on lock screen

[Martin Gräßlin]

On Monday 13 October 2014 17:29:55 Eike Hein wrote:
> On 13.10.2014 17:23, Marco Martin wrote:
> > yes, in the case of slideshow or other weird custom animated backgrounds
> > can still somewhat be synced, but only so far
> 
> An implementation alternative would be what Mac OS X does, maybe:
> OS X used to have a lock screen with a generic wallpaper, but as
> of Mountain Lion it uses whatever was on the background at the
> time the screen gets locked.
> 
> On Qt 5.4 we could:
> 
> - Dump whatever the QQuickItem containing the wallpaper currently
>shows into a temp file (there's convenient API now for dumping
>QQuickItems into offscreen buffers).
> 
> - Use it in the lockscreen if the option is enabled.
> 
> That would bypass the syncing problem entirely and simply give us
> a static shot of the background at lock time.

please keep in mind that screens might get added while the screen is locked.

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: wallpapers on lock screen

[Kai Uwe Broulik]

Hi,

apparently OSX 10.8 Mountain Lion uses the current user's wallpaper, dimmed, 
whereas 10.9 Mavericks uses a generic gray background with Apple logo (with no 
way of changing that - apart from replacing a couple of system files)

Cheers

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

Re: wallpapers on lock screen

[Eike Hein]

On 13.10.2014 17:36, Marco Martin wrote:

On Monday 13 October 2014, Eike Hein wrote:

On 13.10.2014 17:23, Marco Martin wrote:

yes, in the case of slideshow or other weird custom animated backgrounds
can still somewhat be synced, but only so far


An implementation alternative would be what Mac OS X does, maybe:
OS X used to have a lock screen with a generic wallpaper, but as
of Mountain Lion it uses whatever was on the background at the
time the screen gets locked.


does it always show just that? is it configurable?


It's not easily configurable, but it seems third-party apps exist
for it:

http://superuser.com/questions/571464/how-do-i-change-the-lock-screen-image-on-os-x


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

Re: wallpapers on lock screen

[Marco Martin]

On Monday 13 October 2014, Eike Hein wrote:
> On 13.10.2014 17:23, Marco Martin wrote:
> > yes, in the case of slideshow or other weird custom animated backgrounds
> > can still somewhat be synced, but only so far
> 
> An implementation alternative would be what Mac OS X does, maybe:
> OS X used to have a lock screen with a generic wallpaper, but as
> of Mountain Lion it uses whatever was on the background at the
> time the screen gets locked.

does it always show just that? is it configurable?

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

Re: wallpapers on lock screen

[Eike Hein]

On 13.10.2014 17:23, Marco Martin wrote:

yes, in the case of slideshow or other weird custom animated backgrounds can
still somewhat be synced, but only so far


An implementation alternative would be what Mac OS X does, maybe:
OS X used to have a lock screen with a generic wallpaper, but as
of Mountain Lion it uses whatever was on the background at the
time the screen gets locked.

On Qt 5.4 we could:

- Dump whatever the QQuickItem containing the wallpaper currently
  shows into a temp file (there's convenient API now for dumping
  QQuickItems into offscreen buffers).

- Use it in the lockscreen if the option is enabled.

That would bypass the syncing problem entirely and simply give us
a static shot of the background at lock time.

Props for somehow suspending and resuming dynamic wallpapers like
the slide show while locked, if the plugin API allows for that, so
there's no sync problem on unlock, too.


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

Re: wallpapers on lock screen

[Marco Martin]

On Monday 13 October 2014, Eike Hein wrote:
> On 13.10.2014 17:19, Marco Martin wrote:
> > not really, just the lockscreen view would load the qml files used for
> > system wallpapers now, and then they should just "automagically work" by
> > default would just be the image wallpaper that by default uses the image
> > specified in the plasma theme, so would still be l&f package dependent
> 
> And what if the user uses a slide show with a couple of custom
> pictures? You'd need to both sync that config *and* what image
> it's currently on, if the idea here is a smooth visual transi-
> tion without perceived glitches.

yes, in the case of slideshow or other weird custom animated backgrounds can 
still somewhat be synced, but only so far

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

Re: wallpapers on lock screen

[Aleix Pol]

On Mon, Oct 13, 2014 at 5:11 PM, Marco Martin  wrote:

> On Monday 13 October 2014, Eike Hein wrote:
>
> >
> > Still, adding the functionality to pick up the current or a
> > custom wallpaper is fine if done correctly, of course, but not
> > as a default IMHO.
>
> instead of some automagic and default i was more thinking about some
> option in
> the ordinary wallpaper settings "use this in the lockscreen" maybe
> unchecked
> by default
>

+1

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

Re: Re: wallpapers on lock screen

[Martin Gräßlin]

On Monday 13 October 2014 16:44:30 Martin Klapetek wrote:
> I think by default it should use the (current visible) desktop wallpaper in
> the lockscreen.

for privacy reasons the current configured wallpaper should not be used in the 
lock screen (or splash screen or whatever).

Having a checkbox "also use on lock screen" sounds like a good solution, 
though.

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: wallpapers on lock screen

[Eike Hein]

On 13.10.2014 17:19, Marco Martin wrote:

not really, just the lockscreen view would load the qml files used for system
wallpapers now, and then they should just "automagically work" by default
would just be the image wallpaper that by default uses the image specified in
the plasma theme, so would still be l&f package dependent


And what if the user uses a slide show with a couple of custom
pictures? You'd need to both sync that config *and* what image
it's currently on, if the idea here is a smooth visual transi-
tion without perceived glitches.

And if not ... why add a hack that only works in a constrained
scenario instead of across the customization options we actually
have?


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

Re: wallpapers on lock screen

[Marco Martin]

On Monday 13 October 2014, Aleix Pol wrote:
> I understand that some people really like that idea though, I think the
> best would be to have some kind of checkbox in the wallpaper chosing dialog
> or lockscreen kcm that says use wallpaper for the lockscreen but I'm still
> afraid that this will complicate the code, given that it will require
> moving wallpaper-rendering code over to the l&f theme.

not really, just the lockscreen view would load the qml files used for system 
wallpapers now, and then they should just "automagically work" by default 
would just be the image wallpaper that by default uses the image specified in 
the plasma theme, so would still be l&f package dependent


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

Re: wallpapers on lock screen

[Aleix Pol]

On Mon, Oct 13, 2014 at 4:09 PM, Marco Martin  wrote:

> Hi all,
>
> this is already 5.2 stuff, but just to discuss.
> we still have one burned-in fixed wallpaper for the lock screen, so at this
> point it should get a bit of attention.
>
> one thing i'm not sure to do if i want to have again the possibility to put
> widgets in the lock screen as it was in kde4. there may be interests on it,
> but on the other hand i am not seeing much complaints that at the moment is
> missing.
>
> on either case, should be very easy to recycle the complete wallpaper
> mechanism of plasmashell, even the qml only wallpapers (that if animated..
> yay, screensavers!)
>
> just to see what path to take do design and implement correctly, if just
> boring wallpapers or full widgets.
>

To be honest, I like it best if the designers (that is, the lookandfeel
package creators) get to design the whole thing, because the look is part
of the lookandfeel.

I understand that some people really like that idea though, I think the
best would be to have some kind of checkbox in the wallpaper chosing dialog
or lockscreen kcm that says use wallpaper for the lockscreen but I'm still
afraid that this will complicate the code, given that it will require
moving wallpaper-rendering code over to the l&f theme.

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

Re: wallpapers on lock screen

[Marco Martin]

On Monday 13 October 2014, Eike Hein wrote:

> 
> Still, adding the functionality to pick up the current or a
> custom wallpaper is fine if done correctly, of course, but not
> as a default IMHO.

instead of some automagic and default i was more thinking about some option in 
the ordinary wallpaper settings "use this in the lockscreen" maybe unchecked 
by default


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

[Powerdevil] [Bug 339391] system hangs during suspend-to-ram (must poweroff), while pm-suspend works.

[Christoph Feck]

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

Christoph Feck  changed:

   What|Removed |Added

   See Also||https://bugs.kde.org/show_b
   ||ug.cgi?id=339911

-- 
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: wallpapers on lock screen

[Eike Hein]

On 13.10.2014 16:44, Martin Klapetek wrote:

I think by default it should use the (current visible) desktop wallpaper
in the lockscreen.


I think that's a bad default for security/privacy reasons. The
purpose of the lock screen is to avoid exposing system state
while the system is unattended; customization is system state,
and moreover custom wallpapers are even user data. The lock
screen should be generic and not pick up any user settings by
default for that reason (except those needed to interact with
the lock screen itself, e.g. the keyboard layout).

This is before we get into the fact that Plasma wallpapers are
technically code plugins and can be dynamic and even interactive
- *actually* picking up the current wallpaper would require kwin 
participation o composite correctly, or running a second instance

of the plugin, and then you run into the difficulty of syncing
config and/or state correctly anyway. Just supporting images
would be an incomplete hack.

Still, adding the functionality to pick up the current or a
custom wallpaper is fine if done correctly, of course, but not
as a default IMHO.




Cheers
--
Martin Klapetek | KDE Developer


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

Re: wallpapers on lock screen

[Marco Martin]

On Monday 13 October 2014, Martin Klapetek wrote:
> I think by default it should use the (current visible) desktop wallpaper in
> the lockscreen.
> 
> Then there could be two options - select custom wallpaper or use the
> current but blurred (Harald has PoC of this and imo it's really cool).

working code, something usable or just hardcoded?

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

Re: wallpapers on lock screen

[Martin Klapetek]

I think by default it should use the (current visible) desktop wallpaper in
the lockscreen.

Then there could be two options - select custom wallpaper or use the
current but blurred (Harald has PoC of this and imo it's really cool).

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

[Powerdevil] [Bug 339391] system hangs during suspend-to-ram (must poweroff), while pm-suspend works.

[Roberto]

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

--- Comment #8 from Roberto  ---
Vincent, could you please test pm-suspend?

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

wallpapers on lock screen

[Marco Martin]

Hi all,

this is already 5.2 stuff, but just to discuss.
we still have one burned-in fixed wallpaper for the lock screen, so at this 
point it should get a bit of attention.

one thing i'm not sure to do if i want to have again the possibility to put 
widgets in the lock screen as it was in kde4. there may be interests on it, 
but on the other hand i am not seeing much complaints that at the moment is 
missing.

on either case, should be very easy to recycle the complete wallpaper 
mechanism of plasmashell, even the qml only wallpapers (that if animated.. 
yay, screensavers!)

just to see what path to take do design and implement correctly, if just 
boring wallpapers or full widgets.


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

Plasma 5.1 Changes

[Sebastian Kügler]

Hi,

For the release notes, I've extracted the new and improved stuff in 5.1 from 
the mailinglist, please have a look at 

https://community.kde.org/Plasma/5.1_Changes

and add what you think is missing.

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

[Powerdevil] [Bug 339391] system hangs during suspend-to-ram (must poweroff), while pm-suspend works.

[Lukáš Tinkl]

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

Lukáš Tinkl  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED
 Ever confirmed|0   |1

--- Comment #7 from Lukáš Tinkl  ---
PowerDevil uses systemd's login1 interface, so if pm-suspend (which is
something different) works, then systemd is to blame. If neither pm-suspend
works, it must be a kernel or even HW issue.

-- 
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 339391] system hangs during suspend-to-ram (must poweroff), while pm-suspend works.

[Roberto]

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

--- Comment #6 from Roberto  ---
In my case also pm-suspend doesn't work, see Comment #1 above.
In fact, I think powerdevil calls pm-suspend via dbus, so it's the same.

I've noticed that standby and shutdown work if the system is just powered on,
while if you wait some time (half an hour or something like this) then they no
longer work.

-- 
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 339391] system hangs during suspend-to-ram (must poweroff), while pm-suspend works.

[Vincent Petry]

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

--- Comment #5 from Vincent Petry  ---
I'm not sure. We'd need to find how powerdevil is doing the suspending.
You said that pm-suspend always work ? I haven't tried it yet but will later.

If pm-suspend works and not powerdevil we need to look at what happens in
between, maybe find related logs which could contain clues.

-- 
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 339391] system hangs during suspend-to-ram (must poweroff), while pm-suspend works.

[Roberto]

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

--- Comment #4 from Roberto  ---
Hi Vincent,

I have not reported anywhere, because I was thinking about an hardware problem.
It is unlikely that linux cannot shutdown a system... What do you think?

-- 
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 339391] system hangs during suspend-to-ram (must poweroff), while pm-suspend works.

[Vincent Petry]

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

--- Comment #3 from Vincent Petry  ---
This is with KDE 4.14.1-1.2.x86_64.

Note that before switching to openSUSE Factory I used openSUSE 13.1 and it
worked correctly there, so possibly a regression.

-- 
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 339391] system hangs during suspend-to-ram (must poweroff), while pm-suspend works.

[Vincent Petry]

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

Vincent Petry  changed:

   What|Removed |Added

 CC||pvinc...@yahoo.fr

--- Comment #2 from Vincent Petry  ---
I know this is not related to KDE but wanted to point out that I randomly got
the same issue, also on a Dell XPS 13. Using openSUSE Factory with kernel
3.16.4-1.g7a8842b-desktop.

I also have no swap space set. I've enabled it now and we'll see whether it
solves the issue in the long run.

Roberto, did you report this issue in other places ? Kernel bug ?

-- 
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 120276: Initial port to frameworks for the comic dataengine.

[Martin Klapetek]

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



dataengines/comic/CMakeLists.txt


Is the KDELibs4Support needed only because of the KStandardDirs? If yes, 
then let's port away from that as well, it's easy enough



dataengines/comic/CMakeLists.txt


These two could be merged into one



dataengines/comic/comic_package.cpp


These should use the <> brackets



dataengines/comic/comic_package_plugin.cpp


I think this should just go into comic_package.cpp to follow all the other 
exports, then this file can be removed



dataengines/comic/comicproviderkross.cpp


This should use the <> brackets



dataengines/comic/comicproviderkross.cpp


Remove if not needed



dataengines/comic/comicproviderwrapper.cpp


The coding style is no spaces inside ()s (I know it's not your code, but 
since you're touching it already, let's fix it)

Also, do we need all this kind of information actually printed in the log?



dataengines/comic/comicproviderwrapper.cpp


No spaces in ()s



dataengines/comic/comicproviderwrapper.cpp


No spaces in ()s


- Martin Klapetek


On Oct. 12, 2014, 6:06 p.m., Andrei Amuraritei wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120276/
> ---
> 
> (Updated Oct. 12, 2014, 6:06 p.m.)
> 
> 
> Review request for Plasma, David Edmundson, Marco Martin, and Sebastian 
> Kügler.
> 
> 
> Repository: kdeplasma-addons
> 
> 
> Description
> ---
> 
> comic DataEngine initial port to frameworks.
> 
> 
> Diffs
> -
> 
>   dataengines/comic/comicproviderkross.h 46a9072 
>   dataengines/comic/comicproviderkross.cpp 9820f05 
>   dataengines/comic/comicproviderwrapper.h 81eee68 
>   dataengines/CMakeLists.txt 04c7985 
>   dataengines/comic/CMakeLists.txt 8e382e6 
>   dataengines/comic/cachedprovider.h baac8a9 
>   dataengines/comic/cachedprovider.cpp caca25e 
>   dataengines/comic/comic.h 8cc3969 
>   dataengines/comic/comic.cpp 7130f44 
>   dataengines/comic/comic_package.h 32be381 
>   dataengines/comic/comic_package.cpp 6d2ff0b 
>   dataengines/comic/comic_package_plugin.cpp d997947 
>   dataengines/comic/comicprovider.h 630ee8d 
>   dataengines/comic/comicprovider.cpp ab248a5 
>   dataengines/comic/comicproviderwrapper.cpp 48ced42 
> 
> Diff: https://git.reviewboard.kde.org/r/120276/diff/
> 
> 
> Testing
> ---
> 
> Building from source, compiles 100%, some deprecated warnings. DataEngine 
> shows up in plasmaengineexplorer and detects installed .comic packages.
> This is the initial port, still need to review code to fix issues like 
> whitespaces around ( or the deprecated parts.
> Thanks notmart, d_ed, sebas, bshas etc for helping.
> 
> 
> Thanks,
> 
> Andrei Amuraritei
> 
>

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

Re: Review Request 120565: Save the default file manager into the group [Default Applications]

[David Faure]

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

Ship it!


Looks correct. The addition to "Added Applications" is obsoleted by this, I 
guess you're keeping it for old implementations, that's fine.

Hmm, well, kservice/src/kbuildsycoca/kmimeassociations.cpp is such an "old" 
implementation, it doesn't read Default Applications yet :-)
That's something else you might want to fix ;)

- David Faure


On Oct. 12, 2014, 6:03 p.m., Luc Menut wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120565/
> ---
> 
> (Updated Oct. 12, 2014, 6:03 p.m.)
> 
> 
> Review request for Plasma and David Faure.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> Save the default file manager (inode/directory) by writing into the group 
> [Default Applications] in the file mimeapps.list, as per the mime-apps spec 
> 1.0.1 .
> http://standards.freedesktop.org/mime-apps-spec/mime-apps-spec-1.0.1.html#default
> 
> keditfiletype (kde-cli-tools) already saves the default application for a 
> given mimetype (including inode/directory for file manager) in [Default 
> Applications] since
> http://quickgit.kde.org/?p=kde-cli-tools.git&a=commit&h=32bf8f704f174f2652aadf442b07fb10c597a327
> 
> regards,
> 
> Luc Menut - Mageia
> 
> PS: I don't have write access to kde git, so could you commit the change if 
> the patch looks fine. Thanks.
> 
> 
> Diffs
> -
> 
>   kcms/componentchooser/componentchooserfilemanager.cpp b23bfa0 
> 
> Diff: https://git.reviewboard.kde.org/r/120565/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Luc Menut
> 
>

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

Re: Fwd: Plasma Framework problems

[Marco Martin]

On Sunday 12 October 2014, David Edmundson wrote:
> On 12 Oct 2014 18:04, "šumski"  wrote:
> > On Sunday 12 of October 2014 11:58:44 David Edmundson wrote:
> > > > I'll report back when I've confirmed this and then we can work out
> 
> how we
> 
> > > > proceed.
> > > > 
> > > > Reverting a3932843386a29faa3c62bf2934a173a3781d56c does indeed make
> > > 
> > > everything work.
> > > 
> > > Assuming we don't have a time machine our options are:
> > >  - revert this commit and release plasma-framework 5.3.1 really quickly
> > 
> > Please go with this option...
> 
> I need approval from Marco and other David.

after a quick chat with David E this morning, I would revert that patch (and 
then remove the plugin in plasma-workspace master)
*but* this only if there will be a 5.3.1 (there should be a fix in 
kwindowsystem as well as far i understood, so would be good a 5.3.1 release 
with both fixes)

-- 
Marco Martin
___
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, 13-10-2014

Present: Aleix, David, Kai Uwe, Marco, Martin G., Martin K., Jonathan, Harald, 
Jens, Sebastian

For updates on TODO/status, see also Kanban board at: 
https://todo.kde.org/?controller=board&action=show&project_id=13

David:
- Investigating breakage of new Plasma with older frameworks
- discussing solution, problem is about a codepath duplication in a plugin and 
hardcoded

Aleix:
- Please let him know if there are problems with moving repos to workspace
- Attended Qt DevDays last week
- Has RR about making QIconItem use TextureNode

Kai Uwe:
- investigating where porting to Animator would make sense in Plasma (to 
reduce CPU load)

Marco:
- bug hunting and  fixing
- especially bugs with single screen, should work fine now

Martin G:
- Attended XDC (see blog at 
http://blog.martin-graesslin.com/blog/2014/10/xdc-2014/ )
- will work on "subcompositor" next
- Keeps focus on Wayland

Jonathan:
- Working on release bits (information, mainly)

Harald:
- Blue Systems is creating weekly isos again now
- based on Kubuntu production packages with CI
- working on PA mixer

Martin K:
- Bug triaging
- Working on KAccounts

Jens:
- Looking for a dev to work on systemsettings
- Discussing changes in Oxygen between Qt4 and Qt5 version

Sebastian:
- Worked on promo
- KWayland addition of wl_display_sync in API almost done
- to make sure 5.1 gets out, then back to Wayland kscreen, 
- perhaps bit of pluginloader


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

5.1 Errata

[Jonathan Riddell]

As discussed at hangout, if you know of bugs which users should be aware of
please add them to

https://community.kde.org/Plasma/5.1_Errata

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

Re: Review Request 120471: Add Registry::sync() signal

[Martin Gräßlin]

> On Oct. 8, 2014, 9:46 a.m., Martin Gräßlin wrote:
> > src/client/registry.cpp, line 119
> > 
> >
> > this would crash - please use a test case for it. The destroy is 
> > intended to be used to clean up cleanly in case the Wayland connection 
> > died. So calling into any wayland client library call would crash. There 
> > should be a test for destroy handling, please extend that one.

I just added a WaylandPointer (see 
http://commits.kde.org/kwayland/e213c4717ffba42952753540e27200a93d814cf4 ) 
which makes the whole process much easier. Declare your wl_callback as:
WaylandPointer callback;

and then just do in ::release():
d->callback.release();
and in ::destroy():
d->callback.destroy();


- Martin


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


On Oct. 7, 2014, 11:12 a.m., Sebastian Kügler wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120471/
> ---
> 
> (Updated Oct. 7, 2014, 11:12 a.m.)
> 
> 
> Review request for kwin, Plasma and Martin Gräßlin.
> 
> 
> Repository: kwayland
> 
> 
> Description
> ---
> 
> Add Registry::sync() signal
> 
> Emitted when the Wayland display is done flushing the initial interface
> callbacks, announcing wl_display properties. This can be used to compress
> events. Note that this signal is emitted only after announcing interfaces,
> such as outputs, but not after receiving callbacks of interface properties,
> such as the output's geometry, modes, etc..
> This signal is emitted from the wl_display_sync callback.
> 
> For this, we add a wl_callback_listener to the registry's Private,
> enqueue its events properly, if necessary, and trigger the signal
> through a callback mechanism similar to the wl_registry callbacks.
> 
> This signal allows users of the API to find out when the signal
> emissions, such as outputAnnounced, etc. for all currently existing
> interfaces is complete.
> 
> 
> Diffs
> -
> 
>   autotests/client/test_wayland_registry.cpp 571be0f 
>   src/client/registry.h 9e63a2b 
>   src/client/registry.cpp 22f9484 
> 
> Diff: https://git.reviewboard.kde.org/r/120471/diff/
> 
> 
> Testing
> ---
> 
> tests in libkscreen exercise this feature, it works as expected, meaning I 
> can notify when all initial synchronization is done.
> 
> 
> Thanks,
> 
> Sebastian Kügler
> 
>

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

Re: Plasma 5.1.0

[Sebastian Kügler]

On Thursday, October 09, 2014 21:36:58 Albert Astals Cid wrote:
> El Dijous, 9 d'octubre de 2014, a les 14:26:48, Jonathan Riddell va 
escriure:
> > Plasma 5.1.0 tars up now at
> >
> >  http://starsky.19inch.net/~jr/tmp/plasma-5.1.0/
> >
> > and coming soon to depot
> >
> > 
> >
> > sha256 sums at
> >
> >  https://www.kde.org/info/source-plasma-5.1.0.inc
> > 
> >
> > Release due on Tuesday.
> 
> 4.14.2 release is also on Tueday, maybe i should move it to wednesday?

I think that would make sense. I'm prepping the Plasma 5.1.0 release notes 
now. If need be, we can also push that one one day forward.

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: Plasma 5.1 beta tars

[Jonathan Riddell]

On Sun, Oct 12, 2014 at 05:34:33AM +1100, Michael Palimaka wrote:
> On 09/27/2014 02:13 AM, Michael Palimaka wrote:
> > On 09/26/2014 08:28 AM, Jonathan Riddell wrote:
> >> New in this release..
> >> - standard version number 5.0.95 for all
> > 
> > Does this mean the stuff in extragear is moving to workspace?
> > 
> 
> Any more thoughts about this? Are libkscreen, libmm-qt, & libnm-qt now
> considered to be part of Plasma 5 proper - or are they still just extra
> software that happens to be released at the same time (and now with the
> same version number)?

They're part of Plasma 5 proper and will remain so until the maintainers want 
to move them to KF5 or elsewhere.

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

Re: Should favourites be shared between launchers, and launcher instances?

[Marco Martin]

On Sunday 12 October 2014, Ivan Čukić wrote:
> > i was thinking about an api for the scripting interface to do the
> > defaults.. if preferred:// is used it would be less needed, but could
> > still be useful.
> 
> Is there a particular need for it to be scripted instead of being in a
> global config file?
> 
> I'd say that reading a config file is a bit faster than actually executing
> a javascript function to set the defaults at runtime.

a config file is fine too,
is just another different thing that distributions would have to customize.. 
fine if is well documented, makes the process a bit more complicated tough

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

Re: Fwd: Plasma Framework problems

[Marco Martin]

On Sunday 12 October 2014, David Edmundson wrote:

> > > 
> > > Assuming we don't have a time machine our options are:
> > >  - revert this commit and release plasma-framework 5.3.1 really quickly
> > 
> > Please go with this option...
> 
> I need approval from Marco and other David.
> 
> David

eh no, that commit was correct. that code was moved in a plugin, so it must 
not be in two places.

either it stays as is , or the plugin is removed from plasma-workspace, 
causing other similar problems of synchronization between p-f and p-w

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

Re: Review Request 120568: Save the default browser into the group [Default Applications]

[David Faure]

> On Oct. 12, 2014, 8:51 p.m., David Faure wrote:
> > kcms/componentchooser/componentchooserbrowser.cpp, line 102
> > 
> >
> > No, I am very much against this.
> > 
> > The whole point of "use the right KDE app" is to use the right KDE app, 
> > not to fire up kfmclient_html for everything including text files, images, 
> > calligra documents etc.
> > The "html" suffix is especially wrong since it would try to use 
> > khtmlpart or webkitpart for all of this (explicit mimetype on the 
> > command-line).
> > At least using kde-open would work for all mimetypes, but this is 
> > slower (one more intermediate process) than letting the calling app use 
> > KRun directly.
> > 
> > I know that gnome saves the webbrowser as x-scheme-handler/http, but I 
> > have always considered this a mistake (and we discussed it at length on the 
> > xdg list, so the status quo will remain).
> > 
> > One solution would be to keep this code (with kde-open) but then 
> > special case "if the http scheme handler is kde-open then use KRun 
> > directly" in the kio code that looks up x-scheme-handler stuff (grep says: 
> > KRun and DesktopExecParser).
> 
> Luc Menut wrote:
> Sadly, there is no agreement on the way to save the user preference 
> regarding default browser.
> In this situation, mimeapps.list / x-scheme-handler/http became de facto 
> a standard, even on xdg.lists.freedesktop.org by non-gnome guys.
> So, currently, KDE's users have to set this manually.
> 
> kfmclient_html.desktop is probably not the right choice, but I think that 
> we should really improve this point in KF5 or Plasma, even if it isn't 
> perfect.

If everyone else wants to fire up a browser when clicking on a link to a .odt 
file, that's their choice. I still maintain that we can do better, thanks to 
KIO.

Improving: yes, and I described how. Make a desktop file for kde-open, use that 
when the user selects "use KIO" in the GUI (which is the default, so KDE-based 
distros should also set this by default), and short-circuit that in KRun and/or 
DesktopExecParser to avoid the kde-open indirection.


- David


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


On Oct. 12, 2014, 8:40 p.m., Luc Menut wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120568/
> ---
> 
> (Updated Oct. 12, 2014, 8:40 p.m.)
> 
> 
> Review request for Plasma and David Faure.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> Save the default browser by writing x-scheme-handler/http and 
> x-scheme-handler/https into the group [Default Applications] in the file 
> mimeapps.list .
> Nowadays, many applications look at user preferences for 
> x-scheme-handler/http to determine the default browser, so setting this value 
> would increase interoperability with these applications.
> 
> regards,
> 
> Luc Menut - Mageia
> 
> PS: I don't have write access to kde git, so could you commit the change if 
> the patch looks fine. Thanks.
> 
> 
> Diffs
> -
> 
>   kcms/componentchooser/componentchooserbrowser.cpp 61af1fd 
> 
> Diff: https://git.reviewboard.kde.org/r/120568/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Luc Menut
> 
>

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

Re: Review Request 120568: Save the default browser into the group [Default Applications]

[David Faure]

> On Oct. 13, 2014, 1:16 a.m., Aleix Pol Gonzalez wrote:
> > Wouldn't it make sense to have this within KToolInvocation? It's 
> > responsible for chosing what's the default browser already. In any case we 
> > want it in sync.

Yes, if we always set x-scheme-handler/http, then ktoolinvocation_x11.cpp can 
read that instead of BrowserApplication. But that's basically compatibility the 
other way around (KDE apps reading the scheme-handler setting set by other 
environments), so that's for a separate patch (this one is about KDE workspace 
setting scheme-handler for non-KDE apps to see).


- David


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


On Oct. 12, 2014, 8:40 p.m., Luc Menut wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120568/
> ---
> 
> (Updated Oct. 12, 2014, 8:40 p.m.)
> 
> 
> Review request for Plasma and David Faure.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> Save the default browser by writing x-scheme-handler/http and 
> x-scheme-handler/https into the group [Default Applications] in the file 
> mimeapps.list .
> Nowadays, many applications look at user preferences for 
> x-scheme-handler/http to determine the default browser, so setting this value 
> would increase interoperability with these applications.
> 
> regards,
> 
> Luc Menut - Mageia
> 
> PS: I don't have write access to kde git, so could you commit the change if 
> the patch looks fine. Thanks.
> 
> 
> Diffs
> -
> 
>   kcms/componentchooser/componentchooserbrowser.cpp 61af1fd 
> 
> Diff: https://git.reviewboard.kde.org/r/120568/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Luc Menut
> 
>

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