libs/kworkspace/kdisplaymanager.cpp mess

Àlex Fiestas afiestas at kde.org
Tue May 7 21:21:46 BST 2013


Would be nice to have some kind of unittests on this, that will make a
different with the current implementation (which afaik it has none)


On Mon, May 6, 2013 at 4:14 PM, Martin Briza <mbriza at redhat.com> wrote:

> Well, as I said last week, I started working on it.
> First few commits are in branch mbriza/kdisplaymanager-split.
> Currently, PLEASE, don't judge me for the KDMBackendPrivate class stuff.
> :) I have just cut that out of KDisplayManager, not really knowing what to
> do with it further. I'll try to merge it in the code tomorrow in a fashion
> that doesn't look so horrible and is shared only for the classes which
> really do need it.
>
> I'm pretty sure it doesn't work in this state because all the
> initializations (and static storage of the pointers to the backends) aren't
> complete yet. But it at least compiles.
>
> Regarding design:
> I removed all OldGDM and OldKDM code.
> In the end, it seems two backends will be needed:
>  * One to communicate with something that manages sessions
> (systemd-logind, CK, the DM itself) to be able to switch them. I'm naming
> the classes <something>SMBackend - SM as for Session Manager.
>  * The second to be able to control the DM to make it possible to command
> it to create a new greeter on an other VT. The classes are called
> <something>DMBackend - as for Display Manager.
>
> Currently, I have added the following SM Backends: Null, Login1,
> ConsoleKit and Basic (contains all the previous code) and the following DM
> Backends: Null, DBus (previously called LightDM), Basic (again, with the
> old code).
>
> What I'm not sure about are inheritance chains. I think it would be nice
> to be able to use multiple backends when it's possible, for example we can
> try to shut down the computer using systemd-logind, if it fails, there
> still can be CK and when both fail, there's still possibility to call
> shutdown directly.
>
> Of course there's still a lot of mess left and coding standards aren't
> exactly followed but I'll fix that when the work is done completely.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20130507/aa83c5e4/attachment.htm>


More information about the kde-core-devel mailing list