Announcement
Collapse
No announcement yet.
LightDM Display Manager 2022 Status Update: Not Much Going On
Collapse
X
-
Originally posted by FireBurn View PostI fear SDDM is going the same way, looks like nothing happens for months on end, then there will be a flurry of activity, then nothing again, not been a new release since 2020
Originally posted by archkde View PostFrom scratch doesn't make any sense at all, forking SDDM would be a much better starting point.
Originally posted by luno View Posthttps://wiki.archlinux.org/title/Greetd works perfectly with many frontends for Qt ,GTK , Wlr and many more it is pretty lightweight
Originally posted by Luke_Wolf View PostThey're actually not that big of programs, from scratch actually does make perfect sense.
LightDM is 2.5k LOC
SDDM is 16k LOC
GDM is 65k LOC
The real question is why are they basically all dead?
Comment
-
Originally posted by Awesomeness View Postsddm has always been a stupid decision. KDE already had a perfectly fine LightDM front-end in the late Plasma 4.x era. Then discussions came up what to do with KDM and instead of sticking with LightDM and improving on it, a few but loud KDE developers insisted on sddm. They said that they wouldn't even contribute a Wayland back-end to LightDM because of its CLA (the CLA sucks but that's all I agree with) and they also would not support a LightDM fork because it would be "hostile" which is an absolutely insane claim to make because the GPL already gave them permission to fork which is nothing hostile at all. In the end the loud minority never did anything of substance in sddm. KDE should have never listened to them and listen to the lightdm-kde maintainers.
The option to fork is a moot point here: if you're already going to diverge then you may as well get to choose how you want the whole project to be, i.e. roll your own if you want. The point of reusing another GPL is, in part, to share the codebase between the two.
Originally posted by Awesomeness View Postgreetd is like LightDM (same concepts) but without the CLA which a fork could also have achieved. I don't see the point of greetd reinventing the wheel but I guess LightDM greeters could be ported over, though.... Looking at https://git.sr.ht/~kennylevinsen/greetd/log the fact that greetd only receives one commit every few months, it looks in a worse situation than LightDM https://github.com/canonical/lightdm/commits/main
Comment
-
Originally posted by FireBurn View Post- 3 Nov 2020 - and a dollar short
I hope that soon you will come to have wayland by default and at that point it is important to have native SDDM support on wayland, even if it is not essential.
Simply put, there is not all this rush.
Comment
-
Originally posted by sinepgib View PostThe option to fork is a moot point here: if you're already going to diverge then you may as well get to choose how you want the whole project to be, i.e. roll your own if you want.
Originally posted by sinepgib View PostThe point of reusing another GPL is, in part, to share the codebase between the two.
A possible KDE fork could have continued to take code from upstream and concentrated on Wayland support.
Originally posted by sinepgib View PostDoes LightDM allow a command line greeter?
Comment
-
Originally posted by Awesomeness View PostYou didn't read what you've replied to, right? The KDE developers in charge of the display manager wanted to keep using LightDM or a fork. They decided against it after a hysterical minority that sddm had to be used and that minority then never contributed to sddm despite even though they alluded to be willing on a Wayland port.
Originally posted by Awesomeness View PostOne-way code transfer from Canonical to KDE would have been possible. The point of contention was a Wayland port because back in the day Canonical was dreaming about Mir as an alternative to Wayland.
A possible KDE fork could have continued to take code from upstream and concentrated on Wayland support.
Originally posted by Awesomeness View PostI don't know. Why wouldn't it?
Comment
Comment