KDE applications 4.14 LTS or 4.15?

[Mario Fux]

Morning gals and guys

First: there are several mailing lists in the "TO:" above but please just 
write to the kde-devel mailing list for this discussion.

As the release schedule for our KDE applications in the version 4.14 [1] were 
finalized at the beginning of this week it's time to discuss if 4.14 should 
become a LTS release (e.g. until August 2015 like KDE Workspaces 4.11) or if 
we need (at least) another features release and thus 4.15?

So what do you think? And most important, what do you, the KDE apps 
developers, think? Do you plan to develop new features with Qt4 and the KDE 
Platform 4 or do you plan to port your application to the KDE Frameworks 5 as 
soon as they have a stable release (like this June ;-).

Best regards
Mario

Re: Review Request 117091: Force the screen locker's greeter to show the password input field in case of immediateLock

[Commit Hook]

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


This review has been submitted with commit 
185dfbd70b88e60023742b946473c0eca91b344a by Wolfgang Bauer to branch master.

- Commit Hook


On April 24, 2014, 10:20 p.m., Wolfgang Bauer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117091/
> ---
> 
> (Updated April 24, 2014, 10:20 p.m.)
> 
> 
> Review request for kde-workspace, Plasma and Aaron J. Seigo.
> 
> 
> Bugs: 327947 and 329076
> http://bugs.kde.org/show_bug.cgi?id=327947
> http://bugs.kde.org/show_bug.cgi?id=329076
> 
> 
> Repository: kde-workspace
> 
> 
> Description
> ---
> 
> If the screen locker is set to not require a password to unlock, it will not 
> show the password input field even when the powermanagement settings suspend 
> the system and are set to require a password after resume (when it was 
> already running at that point).
> This locks people out of their system.
> 
> This patch adds a signal handler for SIGUSR1 that switches the running 
> greeter to immediateLock mode. The locker sends that signal to make sure the 
> greeter shows the password input field when necessary.
> 
> 
> Diffs
> -
> 
>   ksmserver/screenlocker/greeter/greeterapp.h 8b79188 
>   ksmserver/screenlocker/greeter/greeterapp.cpp c5e2f85 
>   ksmserver/screenlocker/greeter/main.cpp d898734 
>   ksmserver/screenlocker/ksldapp.cpp 3dfcc9e 
> 
> Diff: https://git.reviewboard.kde.org/r/117091/diff/
> 
> 
> Testing
> ---
> 
> Disable "Require password after" in the screen locker settings (the default), 
> set it to start after 1 min. (for easier testing).
> Enable "Suspend session after" and set it to 2 minutes. (set the action to 
> "Suspend", "Hibernate", or "Lock Screen", doesn't matter)
> Make sure "Lock screen on resume" is enabled in the powermanagements 
> "Advanced Options" (it is by default).
> 
> After 1 minute the screen locker kicks in, and doesn't require a password.
> After 2 minutes the session gets suspended, hibernated or locked, and 
> requires a password to resume.
> 
> Without this patch no password dialog is shown, the user cannot resume the 
> session by entering the password.
> 
> With this patch this works: there is a password input field, the session is 
> unlocked when the user enters the password.
> 
> 
> Thanks,
> 
> Wolfgang Bauer
> 
>

Re: Review Request 117644: screenlocker: don't leave behind screensaver processes

[Commit Hook]

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


This review has been submitted with commit 
b1fa2678d36f6ce215e8d8ec1d57608079f36c89 by Wolfgang Bauer to branch master.

- Commit Hook


On April 24, 2014, 10:28 p.m., Wolfgang Bauer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117644/
> ---
> 
> (Updated April 24, 2014, 10:28 p.m.)
> 
> 
> Review request for kde-workspace and Plasma.
> 
> 
> Bugs: 224200
> http://bugs.kde.org/show_bug.cgi?id=224200
> 
> 
> Repository: kde-workspace
> 
> 
> Description
> ---
> 
> Currently the screen locker just kills the greeter (kscreenlocker_greet) when 
> the screen is unlocked by the user during the grace time.
> But apparently this can leave behind running screensaver processes launched 
> by the greeter, see the bug report (which has the highest number of  votes of 
> all open bugs AFAICS).
> 
> This patch changes this to only terminate the greeter, and adds a signal 
> handler to the greeter to exit gracefully in this case.
> The signal handler exits with return code 1, so that it is not possible to 
> circumvent the password input by just sending a SIGTERM. (the screen locker 
> restarts the greeter in case it doesn't quit with exit code 0)
> 
> 
> Diffs
> -
> 
>   ksmserver/screenlocker/greeter/main.cpp d898734 
>   ksmserver/screenlocker/ksldapp.cpp 3dfcc9e 
> 
> Diff: https://git.reviewboard.kde.org/r/117644/diff/
> 
> 
> Testing
> ---
> 
> Configure a legacy screensaver in Systemsettings->Display and Monitor->Screen 
> Locker, be sure to leave "Require Password after" disabled.
> Wait for the screen locker to kick in.
> Unlock the screen by moving the mouse or pressing a key.
> Check the process list.
> 
> Without this patch at least kswarm.kss and kblankscreen.kss reliably kept 
> running after unlocking the screen on my system.
> With this patch they quit themselves.
> 
> I'm using this patch for over two weeks now, and I haven't seen any left-over 
> screen saver processes any more (and I even set the timeout to 1 minute).
> 
> I also tried to terminate kscreenlocker_greet manually by running "killall 
> kscreenlocker_greet" from a text console in case of a password required, and 
> the locker didn't quit, you still have to enter the password.
> 
> 
> Thanks,
> 
> Wolfgang Bauer
> 
>

Review Request 117779: fix crash when textureNode->texture() is null

[Alexander Richardson]

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

Review request for kde-workspace and Plasma.


Repository: plasma-framework


Description
---

fix crash when textureNode->texture() is null

I get this crash very frequently on my system. This is probably only fixing
the symptom and not the underlying issue, however at least plasma no longer
crashes every few minutes


Diffs
-

  src/declarativeimports/core/windowthumbnail.cpp 
59255f75994adb96b30fb503c759b2e9110ab708 

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


Testing
---

No longer crashes


Thanks,

Alexander Richardson

Re: Review Request 117779: fix crash when textureNode->texture() is null

[Thomas Lübking]

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



src/declarativeimports/core/windowthumbnail.cpp


try before this call.


- Thomas Lübking


On April 25, 2014, 9:41 p.m., Alexander Richardson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117779/
> ---
> 
> (Updated April 25, 2014, 9:41 p.m.)
> 
> 
> Review request for kde-workspace and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> fix crash when textureNode->texture() is null
> 
> I get this crash very frequently on my system. This is probably only fixing
> the symptom and not the underlying issue, however at least plasma no longer
> crashes every few minutes
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/core/windowthumbnail.cpp 
> 59255f75994adb96b30fb503c759b2e9110ab708 
> 
> Diff: https://git.reviewboard.kde.org/r/117779/diff/
> 
> 
> Testing
> ---
> 
> No longer crashes
> 
> 
> Thanks,
> 
> Alexander Richardson
> 
>

Re: Review Request 117779: fix crash when textureNode->texture() is null

[Alexander Richardson]

> On April 25, 2014, 11:44 p.m., Thomas Lübking wrote:
> > src/declarativeimports/core/windowthumbnail.cpp, line 231
> > 
> >
> > try before this call.

Okay, just thought I'd exit early in that case and not bother with the other 
stuff. However is this an appropriate fix, or should it be done somewhere else?


- Alexander


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


On April 25, 2014, 11:41 p.m., Alexander Richardson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117779/
> ---
> 
> (Updated April 25, 2014, 11:41 p.m.)
> 
> 
> Review request for kde-workspace and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> fix crash when textureNode->texture() is null
> 
> I get this crash very frequently on my system. This is probably only fixing
> the symptom and not the underlying issue, however at least plasma no longer
> crashes every few minutes
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/core/windowthumbnail.cpp 
> 59255f75994adb96b30fb503c759b2e9110ab708 
> 
> Diff: https://git.reviewboard.kde.org/r/117779/diff/
> 
> 
> Testing
> ---
> 
> No longer crashes
> 
> 
> Thanks,
> 
> Alexander Richardson
> 
>

Re: Review Request 117779: fix crash when textureNode->texture() is null

[Thomas Lübking]

> On April 25, 2014, 9:44 p.m., Thomas Lübking wrote:
> > src/declarativeimports/core/windowthumbnail.cpp, line 231
> > 
> >
> > try before this call.
> 
> Alexander Richardson wrote:
> Okay, just thought I'd exit early in that case and not bother with the 
> other stuff. However is this an appropriate fix, or should it be done 
> somewhere else?

No idea (don't know the code), but that'd apparently be the crash location 
while the texture might still be generated above - so it has to work here, not 
before.

It would crash because the texture has never been set and just for the function 
name i'd assume that to be the bug.


- Thomas


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


On April 25, 2014, 9:41 p.m., Alexander Richardson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117779/
> ---
> 
> (Updated April 25, 2014, 9:41 p.m.)
> 
> 
> Review request for kde-workspace and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> fix crash when textureNode->texture() is null
> 
> I get this crash very frequently on my system. This is probably only fixing
> the symptom and not the underlying issue, however at least plasma no longer
> crashes every few minutes
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/core/windowthumbnail.cpp 
> 59255f75994adb96b30fb503c759b2e9110ab708 
> 
> Diff: https://git.reviewboard.kde.org/r/117779/diff/
> 
> 
> Testing
> ---
> 
> No longer crashes
> 
> 
> Thanks,
> 
> Alexander Richardson
> 
>

Re: KDE applications 4.14 LTS or 4.15?

[Aleix Pol]

On Fri, Apr 25, 2014 at 9:09 PM, Mario Fux  wrote:

> Morning gals and guys
>
> First: there are several mailing lists in the "TO:" above but please just
> write to the kde-devel mailing list for this discussion.
>
> As the release schedule for our KDE applications in the version 4.14 [1]
> were
> finalized at the beginning of this week it's time to discuss if 4.14 should
> become a LTS release (e.g. until August 2015 like KDE Workspaces 4.11) or
> if
> we need (at least) another features release and thus 4.15?
>
> So what do you think? And most important, what do you, the KDE apps
> developers, think? Do you plan to develop new features with Qt4 and the KDE
> Platform 4 or do you plan to port your application to the KDE Frameworks 5
> as
> soon as they have a stable release (like this June ;-).
>
> Best regards
> Mario
>

I would like to see applications starting to use KF5 more and more. I agree
it can be a special case, but the 3 oldest projects I maintain (KDevelop
which is not in SC, KAlgebra and Kamoso) are mostly ready for action.

On the other hand, I don't see a reason for waiting more to adopt Qt5 on
our projects.

Aleix

Re: Review Request 117779: fix crash when textureNode->texture() is null

[Alexander Richardson]

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

(Updated April 26, 2014, 12:51 a.m.)


Review request for kde-workspace and Plasma.


Repository: plasma-framework


Description
---

fix crash when textureNode->texture() is null

I get this crash very frequently on my system. This is probably only fixing
the symptom and not the underlying issue, however at least plasma no longer
crashes every few minutes


Diffs (updated)
-

  src/declarativeimports/core/windowthumbnail.cpp 
59255f75994adb96b30fb503c759b2e9110ab708 

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


Testing
---

No longer crashes


Thanks,

Alexander Richardson

Re: Review Request 117779: fix crash when textureNode->texture() is null

[Martin Gräßlin]

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


I'd rather not want to see us hide this crash. There is an underlying problem 
which needs a more proper fix. I recently hit this problem myself on one on my 
systems and a crash one can reproduce is as good as fixed ;-)

- Martin Gräßlin


On April 26, 2014, 12:51 a.m., Alexander Richardson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117779/
> ---
> 
> (Updated April 26, 2014, 12:51 a.m.)
> 
> 
> Review request for kde-workspace and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> fix crash when textureNode->texture() is null
> 
> I get this crash very frequently on my system. This is probably only fixing
> the symptom and not the underlying issue, however at least plasma no longer
> crashes every few minutes
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/core/windowthumbnail.cpp 
> 59255f75994adb96b30fb503c759b2e9110ab708 
> 
> Diff: https://git.reviewboard.kde.org/r/117779/diff/
> 
> 
> Testing
> ---
> 
> No longer crashes
> 
> 
> Thanks,
> 
> Alexander Richardson
> 
>