KDM plans and lightDM

Harald Sitter sitter at kde.org
Tue Jun 14 19:26:45 BST 2011

On Tuesday 14 June 2011 17:42:55 Martin Gräßlin wrote:
> On Tuesday 14 June 2011 10:35:49 Harald Sitter wrote:
> > On Tue, Jun 14, 2011 at 8:16 AM, Martin Gräßlin <mgraesslin at kde.org> 
> > > There are of course more issues to think about when considering
> > > using
> > > something in our workspace that's developed by Canonical. What about
> > > we need changes Canonical does not like for what reason ever? Who
> > > of us can work with launchpad and bazaar? It's not the environment
> > > we are used to work with (same true for GNOME devs who want to
> > > participate in development). Personal opinion: if Canonical wants
> > > other to use it as real cross-desktop, the first step should be
> > > move the code into freedesktop's git repository.
> > 
> > Indeed, issues worth considering.
> > 
> > I personally believe that "wanting to have something the other party
> > does not" is really a global issue to all of free software. If I want
> > Amarok to be able to remote control my space ship, but the Amarok
> > developers do not, then there is little I can do about that as a
> > non-contributor. Well, except for trying to convince them from the
> > long-term advantage that such a feature would provide. If however I
> > would want Phonon to have such a feature, it is more likely to get
> > accepted as I am contributor to Phonon. I suppose it is a bit of a two
> > class society for every project those-that-do-stuff vs.
> > those-that-don't. While we should keep this in mind, I do not
> > generally think that it is something to base decisions on. From the
> > preemptive fear of not having 100% of control we'd otherwise have to
> > clone every library we use. Well, actually even the OS. Hello KDEOS ;)
> I don't think a comparison with libraries holds. We use libraries to build
> applications including the DM. But the DM is part of our workspace
> offering. Without a DM we no longer provide a complete workspace
> experience. So this is a completely different toppic and cannot be compared
> with our policies for libraries and other OS integration.

Hm. Yeah. You are right.

> To my knowledge this would also be a novelty that we replace a part of our
> workspace with a 3rd party application.
> As a workspace developer I consider the possibility to align all our
> workspace applications to our needs as very important. Let's just consider
> we would want to start into an activity from the DM... My arguments might
> seem far*fetched, but from an integrated workspace development point of
> view, they aren't (at least IMHO).


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.).
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.
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?

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. 

> > 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.

I'll ask Robert though.


More information about the kde-core-devel mailing list