libs/kworkspace/kdisplaymanager.cpp mess

Martin Briza mbriza at redhat.com
Mon Apr 29 14:48:35 BST 2013


Hi,

On Mon, 29 Apr 2013 09:17:15 +0200, Oswald Buddenhagen <ossi at kde.org>  
wrote:

> On Thu, Apr 25, 2013 at 03:11:25PM +0200, Martin Bříza wrote:
>> To provide reasons why to do it:
>>  - The current state is nearly unmaintainable
>>
> that tiny file? you have a low threshold. ;)

Yeah, that's true :) But thinking of the future it'd be nice to have it  
nice and clean.

>> and having all three (for now) ways of session handling in one file
>> doesn't feel very clean.
>>
> it was the best at the time of creation due to the amount of shared
> code (the old gdm and kdm socket code was identical except for the
> string literals and a few conditionals). the ck code was tacked on later.
> at this point the old gdm code can be probably purged, making the kdm
> code independent. you should do that in a separate first commit.
> the ck and systemd paths may share some code, though. maybe add a
> DBusUtils class.

That seems reasonable, I will keep it in mind.

>> I would leave creating the CK module to somebody who is experienced  
>> with how
>> exactly the whole system works and knows if it is safe.
>>
> good luck with that. i'll do reviews, not a bit more.
> note that partial works (be it regressions or just a highly asymmetrical
> code structure) will not be accepted. if you don't find somebody to do
> the refactoring for you, you need to take the route of minimal
> modification.

It will work the same as it does now but I'll split the systemd code away  
 from the main (let's say "legacy") part of the code. Basically, all the  
functions would be virtual but the inheriting classes would implement the  
functionality on their own.
Until the CK support is split (if it is done at all), it will stay in the  
"legacy" part to not break backwards compatibility.

Kind regards,
Martin




More information about the kde-core-devel mailing list