[Bug 305415] Using on-screen keyboard makes the system freeze
https://bugs.kde.org/show_bug.cgi?id=305415 --- Comment #8 from Maurice de la Ferté maurice.fe...@basyskom.com --- Could you try a 'rm -rf path of mounted archos rootfs' before executing the 'tar' deploying command? Maybe your system is affected by some artefacts of an older installation. I'm using 'rm -rf path of mounted archos rootfs' before updating the rootfs on archos and I'm unable to reproduce the black screen caused by broken compositing. In case its does not help, the 'dmesg' output of your machine could be usefull. -- You are receiving this mail because: You are the assignee for the bug. ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
[Bug 305415] Using on-screen keyboard makes the system freeze
https://bugs.kde.org/show_bug.cgi?id=305415 --- Comment #7 from jean.cay...@gmail.com --- Created attachment 73341 -- https://bugs.kde.org/attachment.cgi?id=73341action=edit My kwinactiverc [Compositing] AnimationSpeed=3 Backend=XRender DisableChecks=true Enabled=true GLDirect=true GLLegacy=false GLTextureFilter=2 GLVSync=false HiddenPreviews=5 OpenGLIsUnsafe=false UnredirectFullscreen=true XRenderSmoothScale=false -- You are receiving this mail because: You are the assignee for the bug. ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: qml screenlocker, again
On Monday 20 August 2012, Martin Gräßlin wrote: the only big issue (and is indeed, quite big) is that is possible to kill the window with ctrl+alt+esc key combo. any idea how to solve this? nasty, that should not be. Solution is to grab the keyboard, but that should actually be done by ksmserver already. yeah, explicitly setting the keyboard grab on the widget seems to solve (instead an eventfilter doesn't seem to do much) and most important: do anyone knows about other blockers that would prevent a merge for 4.10? Three issues come to my mind: * log-in with locked screen (needs adjustment in startkde) hmm, any reason in particular this would be needed or wanted? * plasma package support for lock screens, so that users could implement animations again yeah, using packages may make sense * drop the screensavers and kcm i think the timeout is still (partly) governed by the screensaver timeout, so without that kcm wouldn't make much sense, should be uniquely powermanagement governed timeouts? oh, another thing.. what about widgets on screensaver? is something that we really want to keep? would be probably quite easy to just slap a containment in that view if needed, indeed not sure if we *want* that.. but since now the locker background is fixed to the default wallpaper, using a containment would make easier to configure it. Cheers, Marco Martin ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Re: qml screenlocker, again
On Tuesday 21 August 2012 13:43:56 Marco Martin wrote: Three issues come to my mind: * log-in with locked screen (needs adjustment in startkde) hmm, any reason in particular this would be needed or wanted? * it's a feature currently present * it allows to not stop at KDM - very useful for single user systems * plasma package support for lock screens, so that users could implement animations again yeah, using packages may make sense * drop the screensavers and kcm i think the timeout is still (partly) governed by the screensaver timeout, so without that kcm wouldn't make much sense, should be uniquely powermanagement governed timeouts? sounds reasonable to move it to powermanagement oh, another thing.. what about widgets on screensaver? is something that we really want to keep? should still work, IIRC I adjusted it. Personally I would like to have it as the default, but it's too slow in loading. signature.asc Description: This is a digitally signed message part. ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: qml screenlocker, again
On Tuesday 21 August 2012, Alex Fiestas wrote: On Tuesday 21 August 2012 17:51:55 Martin Gräßlin wrote: should still work, IIRC I adjusted it. Personally I would like to have it as the default, but it's too slow in loading. Then we should try to improve this somehow (Maybe in randa?) I'd really like to have: -Unread messages -Finished jobs -Events -Battery those would be super awesome to have, and I'm sure I'm forgetting things :p a way *may* be loading only the greeter executable with the current qml (with just the difference that the scene would be a corona instance, then, *after* is loaded, instantiating a containment with all eventual applets. so it would solve the problem of the lockscreen loading only after a system goes out of sleep, but slow, still (there isn't much way around the time needed to load a containment full of several applets :/) Cheers, Marco Martin ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Re: qml screenlocker, again
On Tuesday 21 August 2012 19:20:08 Marco Martin wrote: On Tuesday 21 August 2012, Martin Gräßlin wrote: i think the timeout is still (partly) governed by the screensaver timeout, so without that kcm wouldn't make much sense, should be uniquely powermanagement governed timeouts? sounds reasonable to move it to powermanagement oh, another thing.. what about widgets on screensaver? is something that we really want to keep? should still work, IIRC I adjusted it. Personally I would like to have it as the default, but it's too slow in loading. yeah, i see. when asked to close the locker from the toolbox, it seems to try to load its own piece of qml for authentication (going to a black screen, btw) uh that used to work properly and IIRC it loads exactly the same greeter as the normal one. But yeah there is quite some duplication and the best solution would be to have just one locker which support Plasmoids and is fast :-P signature.asc Description: This is a digitally signed message part. ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
