KDM plans and lightDM

[Harald Sitter]

On Tuesday 14 June 2011 22:19:40 Martin Gräßlin wrote:
> On Tuesday 14 June 2011 20:26:45 Harald Sitter wrote:
> <snip>
> 
> > Agreed.
> > 
> > Yet despite having complete control we did not manage to come up with a
> > truly good workspace experience that starts at the DM (power
> > management, good looks, I for one have yet to see a sane UI-wise
> > integration of stuff like fingerprint auth, integration with the
> > workspace like say MS Windows displaying unread mails etc.).
> 
> have these issues been raised in the past? How much on the UI layer is
> possible after the Plasma integration? Has anyone tried to work on these
> points?

I have not the slightest idea. Perhaps we should start that, to the batcave, 
erm wiki!

> Personally I have a completely flicker free boot experience from after GRUB
> to desktop is ready to use on my openSUSE systems, so some of the needs are
> not present for all and maybe just unknown. 

https://build.opensuse.org/package/files?package=kdebase4-
workspace&project=openSUSE%3AFactory
Search for KDM and be surprised. Considering a downstream applies 16 (!!!) 
patches to KDM, something must be wrong (without having looked at them in 
detail, supposedly some of them are just distro integration, although those 
perhaps also might be accomodated better).

> And considering how often
> especially Canonical changed the splash implementation over the last years,
> I'm not surprised we don't run behind the latest idea ;-)

Plymouth is also adopted by Fedora :P
Considering the patch is like 30 lines or so, I do not think that is a valid 
excuse though :P

> Oh and I consider
> Plymouth as legacy as I'm quite sure somone will have the idea to replace
> it with a Wayland Compositor (which would make much more sense).

Ack. For getting that adopted by downstream Wayland first needed to come 
around. But yes, ultimately Wayland will eat all our graphics.

> > So, yes, giving away control is certainly a dangerous thing, and needs
> > to be well throught through and evaluated (if it should happen at all
> > that is). Not just in terms of control but also in terms of feature
> > parity. It certainly would hurt the image of the KDE workspace to
> > switch from a capable, proven, well tested and mature DM to one that
> > does not even measure in terms of features. Let alone reliability.
> 
> My motto for Wayland is: DON'T BREAK THE DESKTOP! We should have that on all
> such things ;-)

+1

> > With that in mind it certainly would be a good idea if everyone who
> > threw up rants and whatnot to actually take a look at the status quo
> > and see if lightdm is a viable alternative for antyhing, and if not how
> > to make KDM provide the experience that we need to keep up with our
> > competition.
> > 
> > Perhaps we should actually first find out what we need?
> 
> I think that is the most important one. Look at what is needed. Personally I
> guess that most of it will be fixed with the Plasma integration work.

Should that ever get finished. Shaun?

> Others will have to be evaluated for their actual need. I also think that
> it might have been better to do that before suggesting a new DM ;-)

Well, I can understand Alex' motivation, the issue he experienced is one that 
is quite awkard and painful and embarassing.
[putting my Kubuntu hat on] Also, just to make one thing clear at UDS the 
consensus was to carry the entire discussion upstream and see if we can get 
KDM to become superior awesome. Apparently there is a rumor around that 
Kubuntu plans on switching to LightDM. That is not true, we are merely 
evaluating the options and what we can do to improve the pre-login experience.

> > Regarding the control issue with regards to workspace integration
> > though... Maybe I misunderstood the architecture of LightDM, but to me
> > it seems that all workspace affecting parts would be in the greeter
> > rather than the base of the DM (I figure that is what we have right now
> > in KDM too). What would be "outsourced", if you will, is the actual
> > logic of the DM, which for the better part has little to do with the
> > workspace experience. We would still be in control of all the UI parts,
> > and the DM logic part is certainly not where most of the valuable UI
> > plunder should go (that also includes fancyness enabling technologies
> > such as Plasma). Sure, regarding the actual display management we would
> > be at the mercy of LightDM and its developers, but from a workspace
> > point of view I reckon there is not all that much to be done in the DM
> > logic.
> 
> Well we don't know and I gave an example with Activity integration in my
> last mail. And I could think of more, like logging-in through a Plasma
> Active device or KWallet unlocking. I think there is more than "just UI"
> which makes up the workspace.

Sure, but there is nothing that prevented us from doing that sorta thing in 
the greeter.

I mean, log in via Plasma Active device, if by that you mean I can use my 
phone to log me on my PC, probably should be done on a broader scope anyway. 
Like "log in through a foobar spec compliant device".

In particular it is my personal believe that a strong separation between DM 
logic and desktop binding/integration magic is beneficial from a structural 
POV. That way you can easily swap the integration bits (QWidgets -> Plasma QGV 
stuff -> Plasma QML stuff?) around without having to poke into the DM stuff at 
all.

> > > > At any
> > > > rate it probably does not make sense to take such things into
> > > > account
> > > > for any technical discussion as long as the system in use is
> > > > easily
> > > > accessible. Otherwise all of free software would be using Git,
> > > > not
> > > > because it is superior, but simply because everyone else does.
> > > 
> > > Actually I think from a workspace point of view it is a technical
> > > issue if one of our applications is hosted in a version control
> > > system that is not git. Especially if it is a bizarre one that is
> > > only used by one distribution. It means that not each workspace
> > > developer is able to easily check out the sources and apply
> > > patches. So yes, sounds very much like an issue to me.
> > 
> > I am not the biggest fan of bazaar either, but I think saying it is only
> > used by one distribution is a bit unfair. Also important projects such
> > as MySQL, Inkscape, Zeitgeist and various GNU projects such as Emacs
> > and Grub use it. I would be very surprised if bazaar packages were not
> > available in every serious distribution. Also unlike git it is not a
> > PITA to use on Windows :P
> > 
> > Anyhow, I do not think this is a topic worth discussing just now.
> > Seeing as we did not even identify LightDM as anything we need or want
> > to use in place of own technology. To me the selection of VCS or
> > development infrastructure at large is at best a political issue.
> 
> Just as a reason why it might be more than a political issue for both KDE
> and GNOME: git would allow to co-host it on our infrastructure for things
> like every KDE-dev is allowed to commit and of course scripty. Same holds
> for GNOME with some other points (no scripty ;-)

I do not deny that it has technical merit, but ultimately getting it changed 
is political. Either one wants to do it or not. Perhaps there are technical 
reasons for the choice of VCS, but more likely just personal motivation like 
"seems closest as I work in the Ubuntu environment". Convincing someone (in 
this case Robert) to change to a system that is more in favor of our 
requirements and preference is however something that can only be resolved (or 
not resolved) through discussion, so for the sake of discussion let's for now 
assume that LightDM would be willing to move to fdo git if we chose it be part 
of our workspace and thus require it be as accessible to the team as possible.

-- 
Harald