If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

SDDM - QML Based Display Manager

Hi,

I am developing QML based display manager. I know for a long there was a high demand in creating a QML interface for KDM. Since this never materialized and KDM codebase is huge and somewhat complicated for me, I took the alternate route and wrote my own display manager from stratch.

Being fond of KISS, I tried to keep code simple and dependencies minimum. Only dependencies are PAM, Xlib and Qt. No dependencies on kdelibs or whatever. Code is around 700 lines according to sloccount. As a result of this featureset is somewhat limited compared to bigger ones: no remote connections, no xdmcp etc. things I had never used anyway.

Themes are done in QML, with a few hooks provided for login, shutdown/reboot etc. You can see how things are done in the default theme. There are no restrictions imposed on theme, you can do whatever you want. But it has to be in Qt4 aka QML1 for now. Qt5 porting will done after qt5 gets a bigger install base and easier availability. After that you will be able to use gpu shader/effects in the display manager. Yaaay!

Code can be downloaded from github repo. Service file for systemd and a PKGBUILD is also provided. You can see the PKGBUILD to understand what gets installed into where.

Patches, bug-reports, constructive criticism and feedback much welcome. Actually themes are very welcome too, default theme is pretty simplistic. We may need some bling-bling themes to show off.

You are using Qt, but it seems like you prefer plains C++? Since you use a lot of things that Qt also has. For inctance, std::cerr = qError(...). QProcess can execute a command for you. QCoreApplication::arguments(); gets a QStringList of command line arguments. and there is much more like this. Your code can be a lot cleaner if you where to use that.

You are using XLib directly. While this might be needed for your case, i do encourage you to write an abstraction layer. The current stuff is still X11, but wayland is really going forward now and in not too many years we well certainly see applications/desktop environments working in there. If you where to have an abstraction than porting SDDM to wayland would be "relatively" easy.

Just some comments thus far
Good luck developing this further, it looks interesting!

You are using Qt, but it seems like you prefer plains C++? Since you use a lot of things that Qt also has. For inctance, std::cerr = qError(...). QProcess can execute a command for you. QCoreApplication::arguments(); gets a QStringList of command line arguments. and there is much more like this. Your code can be a lot cleaner if you where to use that.

You are using XLib directly. While this might be needed for your case, i do encourage you to write an abstraction layer. The current stuff is still X11, but wayland is really going forward now and in not too many years we well certainly see applications/desktop environments working in there. If you where to have an abstraction than porting SDDM to wayland would be "relatively" easy.

Just some comments thus far
Good luck developing this further, it looks interesting!

Thanks for the comments. I will try to address your points below.

I did post the repo url, but phoronix style makes links harder to see. Not enough contrast, I guess.

My initial plan was to restrict the use of Qt to only needed parts. Then I gave up since I was going to use Qt in the same binary anyway, but most parts remained. Also I dont have much experience with QProcess (didnt have much with fork either ), help is welcome.

Xlib usage is pretty limited, just open/close display and default screen size etc. So porting should be easy when needed. Also when porting to qt5, probably a xcb port will be needed too. That would be good time to think about abstractions. I wanted to start simple and expand further as needed.

QML Greeter frontend was called for long before lightdm development begun: This blogpost is from 2009 December: http://www.enricoros.com/blog/2009/1...to-kdm-presto/, first commit for lightdm-kdm-greeter shows 2011-11-29 which is a complete two years later. So they did what I did, took an alternative way. I did just different because dependency on kdelibs is a non-option for some.

Disclaimer: I use KDE and love it. I am not trying to insult any kde or kdm developers in any way. I am grateful for what they provided.