Re: KDM plans and lightDM
A Quarta, 15 de Junho de 2011 17:11:27 Martin Gräßlin você escreveu: > On Wednesday 15 June 2011 17:46:08 Alex Fiestas wrote: > > On Wednesday, June 15, 2011 05:37:14 PM todd rme wrote: > > > There are apparently people willing to implement KDE support in > > > LightDM, so why don't they instead improve KDM? Why should they be > > > putting their effort into an immature project instead of a mature one? > > > > Because they're motivated to work on LightDM and not in KDM, new is > > always attractive. > > Of course everybody is free to spend his time on whatever he wants. But I > consider this as kind of a pity given that it looks like > a) GNOME won't accept lightDM > b) KDE Plasma won't accept lightDM > > which renders lightDM to be used only by Ubuntu and not even by Kubuntu if > they stick to their "we ship what upstream ships". > > I think it would be pretty sad if the workspace community would become > split due to such issues. > > And just as something to remind: there was a time when Lubos seriously > thought about dropping KWin in favor of Compiz, because it was the new > cool kid on the block. Look at what we have today and where Compiz is > today (including their history). Would that have been a wise decision to > drop KWin? Not always is cool and new better than old, stable and feature > rich. +1 > Cheers > Martin -- Nuno Pinheiro | nuno.pinhe...@kdab.com | UI Designer Klarälvdalens Datakonsult AB, a KDAB Group company KDAB - Qt Experts - Platform-independent software solutions
Re: KDM plans and lightDM
On Wed, Jun 15, 2011 at 12:45 PM, Alexander Neundorf wrote: > Seriously, displaying unread emails ? > From which user ? All of them. MSWIN interates through each user in the listview displaying unread mails for each. (it's just a count of unread emails..obviously you don't want other people sifting through some poor bloke's private e-mails ;) -- Shaun Reich, KDE Software Developer (kde.org)
Re: KDM plans and lightDM
On Tuesday 14 June 2011, Harald Sitter wrote: ... > 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.). Seriously, displaying unread emails ? From which user ? Alex
Re: KDM plans and lightDM
On Wednesday, June 15, 2011 05:43:44 PM Martin Gräßlin wrote: > On Wednesday 15 June 2011 12:22:10 Alex Fiestas wrote: > > But right now: (Once again this is what I see from outside:) > > -KDM developers have no plans > > This seems incorrect, given Shaun's work on Plasma - and after the > discussion in this thread this should be known by now. Having somebody working on something doesn't make it a plan. > > -KDM maintainer has no time > > Wouldn't it be an idea to get manpower on KDM? Maybe a better idea than to > invest time in lightDM... Maybe, though lightDM work is almost only about high level stuff, for some people that's funniest. > So my suggestion: let's stop discussing about lightDM and evaluate what we > have and what we need. Let's do it properly and honestly. Then let's look > what can be done in KDM and how we can shuffle resources there. And only > iff that does not work, let's discuss a different DM. And also let's think > about the future. Developing a new DM for X when we are about to switch to > Wayland makes me want to move my palm against my head ;-) > > To me this whole issue was unknown until the thread was started and that > most likely means that it has not been raised on the appropriate > mailinglists. I don't know if it has been raised towards Ossi, but if he > does not have the time there is always the option to bring the discussion > to the plasma mailing list (where you can mostly find all Workspace > interested developers) or on this list here. Though as it is workspace > related, Plasma should be the first choice. Agreed, maybe we can organize a Microsoft Skype meeting or something? IRC has little bandwidth for these discussions imho. Cheers.
Re: KDM plans and lightDM
On Wednesday, June 15, 2011 06:11:27 PM Martin Gräßlin wrote: > On Wednesday 15 June 2011 17:46:08 Alex Fiestas wrote: > > On Wednesday, June 15, 2011 05:37:14 PM todd rme wrote: > > > There are apparently people willing to implement KDE support in > > > LightDM, so why don't they instead improve KDM? Why should they be > > > putting their effort into an immature project instead of a mature > > > one? > > > > Because they're motivated to work on LightDM and not in KDM, new is > > always attractive. > > Of course everybody is free to spend his time on whatever he wants. But I > consider this as kind of a pity given that it looks like > a) GNOME won't accept lightDM They are not going to accept it as GNOME module. > b) KDE Plasma won't accept lightDM You don't have to since nobody propossed to drop KDM in favor of lightDM. > I think it would be pretty sad if the workspace community would become split > due to such issues. I don't see any split, I see 2 guys working on 2 projects not the entire workspace community. > And just as something to remind: there was a time when Lubos seriously > thought about dropping KWin in favor of Compiz, because it was the new cool > kid on the block. Look at what we have today and where Compiz is today > (including their history). Would that have been a wise decision to drop > KWin? Not always is cool and new better than old, stable and feature rich. Agree 100%, though KWin had Lubos, now I know that KDM has SHaun Reich and Ossi, didn't know that before. Please, don't close yourself saying "LightDM is rejected by Plasma team" because plasma has nothing to reject here, if lightDM team does well the work then would be lovely to have support for it as we support many others NIH technologies. And once again just to be 100% crystal clear, NOBODY is saying let's rm -rf KDM and put lightDM instead...
Re: KDM plans and lightDM
On Wednesday, June 15, 2011 05:55:03 PM todd rme wrote: > So in other words when LightDM is mature no one will work on it and we > will be left with the same problem? Maybe, though if it remains active and healthy then we may not.
Re: Re: KDM plans and lightDM
On Wednesday 15 June 2011 17:46:08 Alex Fiestas wrote: > On Wednesday, June 15, 2011 05:37:14 PM todd rme wrote: > > There are apparently people willing to implement KDE support in > > LightDM, so why don't they instead improve KDM? Why should they be > > putting their effort into an immature project instead of a mature one? > Because they're motivated to work on LightDM and not in KDM, new is always > attractive. Of course everybody is free to spend his time on whatever he wants. But I consider this as kind of a pity given that it looks like a) GNOME won't accept lightDM b) KDE Plasma won't accept lightDM which renders lightDM to be used only by Ubuntu and not even by Kubuntu if they stick to their "we ship what upstream ships". I think it would be pretty sad if the workspace community would become split due to such issues. And just as something to remind: there was a time when Lubos seriously thought about dropping KWin in favor of Compiz, because it was the new cool kid on the block. Look at what we have today and where Compiz is today (including their history). Would that have been a wise decision to drop KWin? Not always is cool and new better than old, stable and feature rich. Cheers Martin signature.asc Description: This is a digitally signed message part.
Re: KDM plans and lightDM
On Wed, Jun 15, 2011 at 5:46 PM, Alex Fiestas wrote: > On Wednesday, June 15, 2011 05:37:14 PM todd rme wrote: >> There are apparently people willing to implement KDE support in >> LightDM, so why don't they instead improve KDM? Why should they be >> putting their effort into an immature project instead of a mature one? > Because they're motivated to work on LightDM and not in KDM, new is always > attractive. > > Personally I won't have time to work on LightDM though if I had to work on a > DM I will probably choose LightDM, it is a feel not sure why. So in other words when LightDM is mature no one will work on it and we will be left with the same problem? -Todd
Re: KDM plans and lightDM
On Wednesday, June 15, 2011 05:37:14 PM todd rme wrote: > There are apparently people willing to implement KDE support in > LightDM, so why don't they instead improve KDM? Why should they be > putting their effort into an immature project instead of a mature one? Because they're motivated to work on LightDM and not in KDM, new is always attractive. Personally I won't have time to work on LightDM though if I had to work on a DM I will probably choose LightDM, it is a feel not sure why.
Re: Re: KDM plans and lightDM
On Wednesday 15 June 2011 12:22:10 Alex Fiestas wrote: > But right now: (Once again this is what I see from outside:) > -KDM developers have no plans This seems incorrect, given Shaun's work on Plasma - and after the discussion in this thread this should be known by now. > -KDM maintainer has no time Wouldn't it be an idea to get manpower on KDM? Maybe a better idea than to invest time in lightDM... So my suggestion: let's stop discussing about lightDM and evaluate what we have and what we need. Let's do it properly and honestly. Then let's look what can be done in KDM and how we can shuffle resources there. And only iff that does not work, let's discuss a different DM. And also let's think about the future. Developing a new DM for X when we are about to switch to Wayland makes me want to move my palm against my head ;-) To me this whole issue was unknown until the thread was started and that most likely means that it has not been raised on the appropriate mailinglists. I don't know if it has been raised towards Ossi, but if he does not have the time there is always the option to bring the discussion to the plasma mailing list (where you can mostly find all Workspace interested developers) or on this list here. Though as it is workspace related, Plasma should be the first choice. Cheers Martin signature.asc Description: This is a digitally signed message part.
Re: KDM plans and lightDM
On Wed, Jun 15, 2011 at 12:08 PM, Alex Fiestas wrote: > On Wednesday, June 15, 2011 08:20:35 AM todd rme wrote: >> There seems to be an implicit assumption here that if we are going to >> go the cross-desktop route it would have to be LightDM that we pick. >> But if KDM is already pluggable enough that you can easily rip out the >> GUI and write and entire new one from scratch, and (as best as I can >> tell) already hs most of the features lightDM wants to add, why >> shouldn't we basing the cross-desktop DM on KDM instead of LightDM? > Because at least until I sent the email, everybody thought that KDM was in > "maintenance" mode, meaning only bug fixing. lightDM instead is kick'in hard > and is trying to be cross-platform as possible and they're at least > advertising it as such. > Also, to make something cross-platform you need developers wanting to do the > job, willing to give support etc. Are KDM developers available for that? I'm > truly wondering it don't take my words as retorical or something like that. There are apparently people willing to implement KDE support in LightDM, so why don't they instead improve KDM? Why should they be putting their effort into an immature project instead of a mature one? -Todd
Re: KDM plans and lightDM
On Wed, Jun 15, 2011 at 2:20 AM, todd rme wrote: > I gather from the discussion that most, if not all, the features that > KDM still needs are also lacking in LightDM, while KDM has lots of > features LightDM does not. So if we are talking about wasted > resources, >wouldn't it waste far fewer resources Ex.act.ly. That's precisely what I've been trying to get across this entire time. But instead of adding anything missing to KDM, it's instead added to a different, far less developed project. > to add those new > features and add the Gnome-centric bits in KDM than to add the new > features, old features, gnome-centric bits, and KDE-centric bits in > LightDM? -- Shaun Reich, KDE Software Developer (kde.org)
Re: KDM plans and lightDM
On Tue, Jun 14, 2011 at 6:59 PM, David Edmundson wrote: >Does KDM still run the greeters as root? No. It's been not doing that for about a year or so. -- Shaun Reich, KDE Software Developer (kde.org)
Re: KDM plans and lightDM
On Wed, Jun 15, 2011 at 12:00:00PM +0200, Sebastian Kügler wrote: > 2 takes long to start > > I think lightdm solves (2), but does so by cutting features, features > which we probably need (some asked for XDMCP as an example). > no, it solves it by not using qt+kdeui (and even less plasma). if you adapt xdm's Xt frontend to the backend's last 10 years of development in kde, you will still easily get the fastest dm realistically possible, and demonstrate that kdm is just as "cross-desktopy" as fooDM could ever claim to be. i originally wanted to push my stuff back to X, but the frontend/backend interface is just too unstable to actually have independent projects. i.e., the backend and frontends need to be all in one repo (that may be realistic now, but was a pipe dream at the time i was really active). and fwiw, gdm 2.4+ is also a contender for The Cross Desktop DM. the backend doesn't need anything else than glib (incl. gobject and d-bus bindings), which is about as much as lightDM needs. kdm beats that ...
Re: KDM plans and lightDM
On Tue, Jun 14, 2011 at 11:05 PM, Harald Sitter wrote: > On Tuesday 14 June 2011 14:55:58 Shaun Reich wrote: >> How does lightDM even handle different authentication types? KDM has a >> plugin system which handles different auth types (fingerprint, >> winbindd, etc.). >> >> However, the fundamental flaw that I can see..is that at some level or >> another, the UI/Greeter *has* to know what type of authentication type >> it is. That is why KDM has plugins which wrap around PAM(sort of), so >> that the interface can properly accommodate for the changes in auth >> type. Note these plugins apply to the screensaver unlock dialog as >> well. >> >> I've been toying with the idea in my head, of using the same Plasma >> plugin (actually an applet + dataengine which wraps around a main, >> more generic dataengine) in tandem with the Plasma integration with >> the screensaver, that is currently present. I think it'd be quite >> trivial for me to do this, too -- since I specifically tried to not >> make assumptions. >> >> The plugins exist (both in the plasma frontend and regular kfrontend) >> so that when it's in fingerprint mode..it won't show a textbox or any >> useless stuff like that, and may additionally show a diagram of some >> bloke wiping their finger across. (that's what the kdm plugin does >> actually). >> >> Anyone familiar with the structure in lightDM care to enlighten? > > I am not sure it does right now. LightDM also wraps PAM and then sends the requested type to the greeter. It wraps each service and presents them as one of two methods. showPrompt (display a message and requiring text input) and showMessage(display a message to the user) such as "swipe a finger". This means if you have swipe access login you'll be told to swipe, same for all the 2 factor authentication types requiring additional pin numbers. It is a bit crap at present, but it does work for the vast vast majority of use-cases. Right now the API is not fixed, but I don't think this will change for their first release. I hope we can have a BOF at the desktop to sort this out. It is the one area of LightDM that I think needs some work. I wasn't on KDE-Core-Devel (only KDE Devel), so I've been trying to catch up on the thread from the mailing list thread. So to settle a few things I've read: Bzr vs Git: Only QLightDm (the library between the daemon and Qt greeters) is in the bzr. My currently written KDeclarative greeter engine, and KCM are all in KDE's git in my scratch area. Anything actually KDE related can and should be in our own repos. "We don't have control over it" / "People making us switch": Canonical aren't forcing anyone to switch, in fact it started as an independent project. I approached Robert (the LightDM guy) because LightDM looked cool and to see if I can make something better for my desktop, and for KDE. Robert's been great, and is as open to suggestions as much as anyone working in KDE. Getting involved early in Freedesktop work is by far the best way to shape where we want it to go. Only the backend daemon and client lib are in a different repository (which is still perfectly under our "control"). All the interface stuff is public. Power Management: We have an interface to uPower in the greeter library. It seems to work fine. A KDE Greeter /could/ do something different if it wanted to, but I'm not sure what it would gain. Honest opinion: Right now, it's not as good as KDM. I get all the LightDM bug reports, and they're coming quick and fast. However, it's got a _lot_ of potential. We get a lot work shared - and idea of plugin-able backends for LightDM has we get a lot of cool stuff and future proofing. Wayland support is already on the cards, Plymouth integrates and works. All the little bugs will be fixed before too long, and it will match KDM in stability/features within a few months. Does KDM still run the greeters as root? David Edmundson > > David Edmunson should know. > > -- > Harald >
Re: KDM plans and lightDM
Just to clarify something... I'm not pushing lightDM into KDE in anyway, it is not my favorite DM or anything like that, though I see it as a highly interesting project with a healthy and active community and I do think that KDE should be leading the Qtness of the project as well as be sure that we work well with it. Also, If KDM developers start to implement all the lacking features such: -Power Management -Language switcher - Maybe more? And it becomes at least from the outside point of view a healthy project where incoming patches such the so discussed plymouth one are integrated (I'm not saying integrate it in the current not optimal state, we've reviewboard to improve patches) then I will say, go KDM! since KDM is the KDE solution. But right now: (Once again this is what I see from outside:) -KDM developers have no plans -KDM maintainer has no time And considering that, I think that is not reprehensible if some other developers are attracted by the idea of a cross-platform DM where in theory we will need only to take care about the greeter. So to sum up: We need to improve the DM experiencie in our Workspace, no matter if it is via lightDM, KDM or both. Cheers!
Re: KDM plans and lightDM
On Wednesday, June 15, 2011 08:20:35 AM todd rme wrote: > There seems to be an implicit assumption here that if we are going to > go the cross-desktop route it would have to be LightDM that we pick. > But if KDM is already pluggable enough that you can easily rip out the > GUI and write and entire new one from scratch, and (as best as I can > tell) already hs most of the features lightDM wants to add, why > shouldn't we basing the cross-desktop DM on KDM instead of LightDM? Because at least until I sent the email, everybody thought that KDM was in "maintenance" mode, meaning only bug fixing. lightDM instead is kick'in hard and is trying to be cross-platform as possible and they're at least advertising it as such. Also, to make something cross-platform you need developers wanting to do the job, willing to give support etc. Are KDM developers available for that? I'm truly wondering it don't take my words as retorical or something like that. > I gather from the discussion that most, if not all, the features that > KDM still needs are also lacking in LightDM, while KDM has lots of > features LightDM does not. So if we are talking about wasted > resources, wouldn't it waste far fewer resources to add those new > features and add the Gnome-centric bits in KDM than to add the new > features, old features, gnome-centric bits, and KDE-centric bits in > LightDM? Again, is there anybody willing to do the job? it is always about that...
Re: KDM plans and lightDM
Hi Alex, On Monday, June 13, 2011 21:10:36 Alex Fiestas wrote: > Today something happened to me again, I turn on my laptop at the begining of > a meeting and when I needed it the battery was over because the laptop > didn't went to suspension (as I'm used). > > That makes me wonder what are the plans for KDM in this and other regards > since I haven't seen much activity on it (apart from bugfixing). > > Also, since the last Ubuntu Development Summit I started to look into > lightDM[1] as a possible alternative (at least for my use), I event managed > to patch kdisplaymanager.cpp to play nice with it. > > I'm not an expert on Display Managers so I can't really tell if lightDM is > good enough (or will be good enough) to replace KDM. When I asked to some > distribution people the first thing they told me is: "Does it support > XDMCP?" and I don't know even what XDMCP is... > > So, what are the plans for KDM? can we expect some power management > integration? and plymouth? > > For the experts: Does lightDM feel nice as a cross-desktop solution? is it > good enough? I don't think it's a solution to the problem. LightDM doesn't have any integration with powermanagement agents, so it doesn't solve the problem. Goes a bit like this: - "Hm, KDM doesn't have power management support" - "Let's think about LightDM then!" - "LightDM doesn't have it either" I think it's nice that someone's working on a replacement, but it seems to be kind of chicken-headed. What are the problems with KDM right now? 1 bit arcane UI, litlle themes 2 takes long to start 3 no PM integration 4 no touch input support (Note that the above comes from the top of my head, possibly you can do even one or more, but the default roughly looks like the above. Correct me if I'm wrong, please.) I think lightdm solves (2), but does so by cutting features, features which we probably need (some asked for XDMCP as an example). So lightDM might be useful for a specific situation where you need only the feature set that lightDM offers, On the other hand, KDM is rock-stable, secure and maintained. It's not shiny, and hasn't been built with "devices" in mind. As a result, I'm quite skeptical. But let code decide, not assumptions. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: KDM plans and lightDM
On Wed, Jun 15, 2011 at 1:14 AM, Harald Sitter wrote: > On Tuesday 14 June 2011 15:37:25 Shaun Reich wrote: >> Everybody talks about it like it's some magical unicorn that hasn't >> been spotted before, but the truth is, it's staring everyone in the >> face. >> >> In fact, I have dealt directly with this separation when I've been >> working on the Plasma frontend, and based some of it around the >> original kfrontend (qwidget) code. So I don't see what the big deal >> is, considering I've already worked with this myself... > > My argument was more in the general direction of moving things that we should > not be heavily involved with elsewhere, and I believe that the larger DM logic > is such an area. By outsourcing (what a nice word) this part in technology > that is used by more than one party we get more exposure to actual production > systems, thus more testing and in the end better quality in the long term (not > that anything was wrong with the quality of KDM, just saying). > Now, I reckon that XDM could, or perhaps should, have been exaclty that, > though it did not quite work out. > It still seems like a nice enough idea to share generally sharable things. > > To me, as someone who is not terribly knowledgeable in the area of display > managers, it just seems like a waste of resource to have stuff implemented in > not all that different ways on different ends (GDM and KDM). Though since > there > is no plan to have GDM replaced by LightDM on sytems other than Ubuntu this is > all a bit moot. Even though I think sharing with part of the ecosystem is > still better than no sharing at all. > > -- > Harald > There seems to be an implicit assumption here that if we are going to go the cross-desktop route it would have to be LightDM that we pick. But if KDM is already pluggable enough that you can easily rip out the GUI and write and entire new one from scratch, and (as best as I can tell) already hs most of the features lightDM wants to add, why shouldn't we basing the cross-desktop DM on KDM instead of LightDM? I gather from the discussion that most, if not all, the features that KDM still needs are also lacking in LightDM, while KDM has lots of features LightDM does not. So if we are talking about wasted resources, wouldn't it waste far fewer resources to add those new features and add the Gnome-centric bits in KDM than to add the new features, old features, gnome-centric bits, and KDE-centric bits in LightDM? -Todd
Re: KDM plans and lightDM
On Tuesday 14 June 2011 15:37:25 Shaun Reich wrote: > On Tue, Jun 14, 2011 at 2:58 PM, Harald Sitter wrote: > > Should that ever get finished. Shaun? > > Good question ;-) > Yeah, it's in a pretty finished state, after my unintentional hiatus. > Mostly I've been cleaning stuff up(and yes, I've been actively > committing lately), so that the qml code can look the best. It already > runs plasma and qml and logs in, just have a few more things to do on > it. (kinda refactoring a bit so it doesn't come to bite me later on, > at the moment..) Groovey! > > 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. > > Well, you see. You have to understand my frustration --> the thing is, > this *already* exists in KDM. And anything that is deemed > unsatisfactory(not everything's perfect, naturally) could easily be > changed of course. I very much understand your frustation. But also as downstream developer (and I count Alex in there too as he is very much aware of the advantages of a downstream POV) I get a lot of input with regards to what is not in the condition it should be to compete with other pre-login experiences. Be it from friends or people at fairs, whenever KDM comes up there are some major annoyances (though to put this into perspective: KDM does not come up as topic that often, which IMHO is still a bad thing as I'd rather have people go "uhh, your login thing is so awesome..."). So, to direct attention to the subject. I think the general scheme was to find out where to go with KDM and whether LightDM would be an option if all else fails. Find out how to make KDM rock the user's experience is primary objective, at least for me. > Everybody talks about it like it's some magical unicorn that hasn't > been spotted before, but the truth is, it's staring everyone in the > face. > > In fact, I have dealt directly with this separation when I've been > working on the Plasma frontend, and based some of it around the > original kfrontend (qwidget) code. So I don't see what the big deal > is, considering I've already worked with this myself... My argument was more in the general direction of moving things that we should not be heavily involved with elsewhere, and I believe that the larger DM logic is such an area. By outsourcing (what a nice word) this part in technology that is used by more than one party we get more exposure to actual production systems, thus more testing and in the end better quality in the long term (not that anything was wrong with the quality of KDM, just saying). Now, I reckon that XDM could, or perhaps should, have been exaclty that, though it did not quite work out. It still seems like a nice enough idea to share generally sharable things. To me, as someone who is not terribly knowledgeable in the area of display managers, it just seems like a waste of resource to have stuff implemented in not all that different ways on different ends (GDM and KDM). Though since there is no plan to have GDM replaced by LightDM on sytems other than Ubuntu this is all a bit moot. Even though I think sharing with part of the ecosystem is still better than no sharing at all. -- Harald
Re: KDM plans and lightDM
On Tue, Jun 14, 2011 at 2:58 PM, Harald Sitter wrote: > Should that ever get finished. Shaun? Good question ;-) Yeah, it's in a pretty finished state, after my unintentional hiatus. Mostly I've been cleaning stuff up(and yes, I've been actively committing lately), so that the qml code can look the best. It already runs plasma and qml and logs in, just have a few more things to do on it. (kinda refactoring a bit so it doesn't come to bite me later on, at the moment..) > 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. Well, you see. You have to understand my frustration --> the thing is, this *already* exists in KDM. And anything that is deemed unsatisfactory(not everything's perfect, naturally) could easily be changed of course. Everybody talks about it like it's some magical unicorn that hasn't been spotted before, but the truth is, it's staring everyone in the face. In fact, I have dealt directly with this separation when I've been working on the Plasma frontend, and based some of it around the original kfrontend (qwidget) code. So I don't see what the big deal is, considering I've already worked with this myself... (also note that the Plasma QGV and Plasma QML stuff are kind of one in the same, in the case of my code. one can easily make a qgw as the greeter...of course, I'm using qml. well, unless you're counting things like the scene and the view. but I haven't found a case for moving those to qml yet. not that it'd be that difficult, since it's all modular) -- Shaun Reich, KDE Software Developer (kde.org)
Re: KDM plans and lightDM
On Tuesday 14 June 2011 14:55:58 Shaun Reich wrote: > How does lightDM even handle different authentication types? KDM has a > plugin system which handles different auth types (fingerprint, > winbindd, etc.). > > However, the fundamental flaw that I can see..is that at some level or > another, the UI/Greeter *has* to know what type of authentication type > it is. That is why KDM has plugins which wrap around PAM(sort of), so > that the interface can properly accommodate for the changes in auth > type. Note these plugins apply to the screensaver unlock dialog as > well. > > I've been toying with the idea in my head, of using the same Plasma > plugin (actually an applet + dataengine which wraps around a main, > more generic dataengine) in tandem with the Plasma integration with > the screensaver, that is currently present. I think it'd be quite > trivial for me to do this, too -- since I specifically tried to not > make assumptions. > > The plugins exist (both in the plasma frontend and regular kfrontend) > so that when it's in fingerprint mode..it won't show a textbox or any > useless stuff like that, and may additionally show a diagram of some > bloke wiping their finger across. (that's what the kdm plugin does > actually). > > Anyone familiar with the structure in lightDM care to enlighten? I am not sure it does right now. David Edmunson should know. -- Harald
Re: KDM plans and lightDM
On Tuesday 14 June 2011 22:19:40 Martin Gräßlin wrote: > On Tuesday 14 June 2011 20:26:45 Harald Sitter wrote: > > > > 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
Re: Re: KDM plans and lightDM
Slight shift of topic as well...but: How does lightDM even handle different authentication types? KDM has a plugin system which handles different auth types (fingerprint, winbindd, etc.). However, the fundamental flaw that I can see..is that at some level or another, the UI/Greeter *has* to know what type of authentication type it is. That is why KDM has plugins which wrap around PAM(sort of), so that the interface can properly accommodate for the changes in auth type. Note these plugins apply to the screensaver unlock dialog as well. I've been toying with the idea in my head, of using the same Plasma plugin (actually an applet + dataengine which wraps around a main, more generic dataengine) in tandem with the Plasma integration with the screensaver, that is currently present. I think it'd be quite trivial for me to do this, too -- since I specifically tried to not make assumptions. The plugins exist (both in the plasma frontend and regular kfrontend) so that when it's in fingerprint mode..it won't show a textbox or any useless stuff like that, and may additionally show a diagram of some bloke wiping their finger across. (that's what the kdm plugin does actually). Anyone familiar with the structure in lightDM care to enlighten? -- Shaun Reich, KDE Software Developer (kde.org)
Re: Re: KDM plans and lightDM
On Tuesday 14 June 2011 20:26:45 Harald Sitter wrote: > 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? 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. 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 ;-) 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). > 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 ;-) > 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. 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 ;-) > > 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. > > > > 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 a
Re: KDM plans and lightDM
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 wrote: > > > > 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). 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.). 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
Re: KDM plans and lightDM
On Monday 13 June 2011, Tom Gundersen wrote: > Hi Alex, > > On Mon, Jun 13, 2011 at 9:10 PM, Alex Fiestas wrote: > > For the experts: Does lightDM feel nice as a cross-desktop solution? is > > it good enough? > > I cannot speak to the suitability of lightDM as a KDM replacement. > However, I just wanted to point to a couple of discussions about this > from gnome-land (as one of the aims was to be cross-desktop)[1,2]. > > As to power management: I never quite understood why the power > management policy daemons are implemented inside the DE's. Shouldn't > this be a system-wide daemon, that could be controlled from the DE's > (similarly to what Network Manager is for networking)? This would give > reasonable power management also when logged in from the console, or > as your example illustrates, not logged in at all (at the console or > in the DM). I think so too. This should be a system-wide setting, since it very much influences a system- wide thing. E.g. I don't know what happens if two users are logged in to one laptop (this happens in reality), and they have different power management settings. Somehow (at least with SUSE 11.2...11.4) my laptop also never suspends on closing the lid while the screensaver is active, it only suspends on closing the lid if the screensaver is not active. Is this maybe for a similar reason ? Alex
Re: Re: KDM plans and lightDM
On Tuesday 14 June 2011 10:35:49 Harald Sitter wrote: > On Tue, Jun 14, 2011 at 8:16 AM, Martin Gräßlin wrote: > > On Mon, 13 Jun 2011 16:29:45 -0400, Shaun Reich > > wrote: > >> > >> lightDM is also headed by my dear friend Canonical, as is clearly seen. > > > > Serious question: does anyone know if it requires Canonical's copyright > > assignment to contribute to lightDM? If yes we can stop any further > > discussion right here IMHO. > > robert_ancell: ahoy, is LightDM covered by the > canonical contributor agreement? > apachelogger, no > robert_ancell: ever going to be? > apachelogger, no > apachelogger, the greeter we develop will be afaik, > but the rest of it not Thanks for asking > > > 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. 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). > > I agree with your argument that code should be hosted in a FDO git > repo, though I personally believe that Launchpad is from a management > perspective much easier to use for small projects as it puts every > aspect of management into the hands of the project itself (commit > access to repos, bug management etc. etc.). So, I can completely > understand why one would be using LP even as a freedesktop.org > project/thing, even if I find it not sensible at all to do this while > using the freedesktop.org website, thus fragmenting one's project > *shrug*. > But generally speaking I also see this is as a non-issue in terms of > the discussion at hand. The hosting system in particular is an > implementation detail of forming grounds to collaborate on. Now, to > ask anyone to use a ground we are familiar with (vs. one the other > party is), we'd first have to know that we want to collaborate. Agreed that this is only relevant for the case that we want to use lightDM. > 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. Cheers Martin > > regards, > Harald signature.asc Description: This is a digitally signed message part.
Re: KDM plans and lightDM
On Tue, Jun 14, 2011 at 12:02 AM, Alex Fiestas wrote: > On Monday, June 13, 2011 10:24:22 PM Thomas Lübking wrote: >> Am Mon, 13 Jun 2011 21:34:56 +0200 >> >> schrieb Martin Gräßlin : >> > What does power management has to do with KDM? This belongs into >> > powerdevil where to my knowledge it should be handled fine, if >> > configured correctly. >> >> I guess he means: >> "autosuspension from KDM", ie. w/o being logged in at all - he >> started the system, didn't log in, talked a lot of meeting nonsense >> (tm), legged in - and the battery was sucked away. >> >> I won't comment on the preferred usage of advanced bioneural cpu to >> circumvent such issues in the first place, but this function does imho >> not belong into a DM but into some cron job (or whatever other daemon) >> that watches how long nobody has been logged in and *whether no relevant >> daemon is running* and then suspend the system after some time. > I don't really know what a DM should and should not do, so yes, a cron job > should do the work just fine. How would one do this using a cron job? :O >> This should also cover plymouth (the splashy replacement? really?) - >> but if you mean "bash", you'll require the feature (watching >> keystrokes) there, i think. >> >> Putting this into a DM is rather bad because there's no good default* >> and it's not a DM's job to watch other processes (while maybe other >> logins...) and manage some random blacklist on them. > I'm not sure what's needed to integrate a DM with plymouth (the splashy > replacement), though I know that KDM without patches doesn't have a smooth > transition. There is a patch from the Fedora team that won't be applied into > KDM because it is crappy (ossi says). IIRC the transition is straight forward. Essentially KDM just takes over the VT from plymouth and quits latter once the X server is up and running. Considering the Fedora patch is inferior, it makes me wonder why there was no superior solution created by those that know better. Are distributions not important enough stake holders of KDM? >> *you do not want to suspend your system because you didn't log in since >> (despite starting to runlevel 5...) there's currently some sshd up and >> you're logged into from somewhere else, or just because the machine runs >> a webserver as well... > The 95% of desktop users doesn't use either sshd or a webserver. So at least > this should be configurable. > > GDM loads the "gnome power management" to solve the issue, what KDM does? > can KDM maybe launch kded with some daemons? You'd still need to provide configuration for this, as the point about running servers still holds. IIf you are running a server of whatever kind on your machine and stay at DM while using it, you do not want to have the machine suspend for lack of interaction, so the simplest solution would be to provide an option in the DM KCM "do-not-break-me-server". As for the logged in on tty cas: If I am not mistaken that is exactly what ConsoleKit is supposed to solve. Every login shell you run should AFAIK result in a seat on ConsoleKit. So, except for the server use case that should cover the greater part of false suspension scenarios. > It may no be perfect but lightDM at least does some handling directly talking > to UPower, though I agree that DM is not the place to fix this issue. Agreed. As Tom pointed out, ideally we'd have a desktop independent daemon to take control over power management. By desktop independent I really mean "eventually cross-desktop" (as in: used in >1 desktop env). This would also allow applications to inhibit suspension (think video player) on every desktop that supports the daemon. Though, this is likely not going to happen any time soon, perhaps even never, so a sensible solution ought to be found. Even if not the most elegant, power management in the DM (or invoked by the DM, i.e. kded with powerdevil) seems like a good enough approach to solve the issue for the majority of desktops users. regards, Harald
Re: KDM plans and lightDM
On Tue, Jun 14, 2011 at 8:16 AM, Martin Gräßlin wrote: > On Mon, 13 Jun 2011 16:29:45 -0400, Shaun Reich > wrote: >> >> lightDM is also headed by my dear friend Canonical, as is clearly seen. > > Serious question: does anyone know if it requires Canonical's copyright > assignment to contribute to lightDM? If yes we can stop any further > discussion right here IMHO. robert_ancell: ahoy, is LightDM covered by the canonical contributor agreement? apachelogger, no robert_ancell: ever going to be? apachelogger, no apachelogger, the greeter we develop will be afaik, but the rest of it not > 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 agree with your argument that code should be hosted in a FDO git repo, though I personally believe that Launchpad is from a management perspective much easier to use for small projects as it puts every aspect of management into the hands of the project itself (commit access to repos, bug management etc. etc.). So, I can completely understand why one would be using LP even as a freedesktop.org project/thing, even if I find it not sensible at all to do this while using the freedesktop.org website, thus fragmenting one's project *shrug*. But generally speaking I also see this is as a non-issue in terms of the discussion at hand. The hosting system in particular is an implementation detail of forming grounds to collaborate on. Now, to ask anyone to use a ground we are familiar with (vs. one the other party is), we'd first have to know that we want to collaborate. 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. regards, Harald
Re: KDM plans and lightDM
On Mon, Jun 13, 2011 at 9:34 PM, Martin Gräßlin wrote: > On Monday 13 June 2011 21:10:36 Alex Fiestas wrote: >> So, what are the plans for KDM? can we expect some power management >> integration? and plymouth? > > I don't see what power management and plymouth have to do with KDM. Power > managmeent > is after KDM and plymouth is before KDM. Just my two cents: I think the idea is that while currently Plymouth is before KDM and power managment is after, it would be nicer if this is not the case. I.e., integrate Plymouth with the DM's so it transitions nicely with no flicker on start-up (this I think is the case already in GDM), and integrate the power managment daemons with the DM's, so they can be started before the user logs in (this is also already the case in GDM). -t
Re: KDM plans and lightDM
Hi Alex, On Mon, Jun 13, 2011 at 9:10 PM, Alex Fiestas wrote: > For the experts: Does lightDM feel nice as a cross-desktop solution? is it > good enough? I cannot speak to the suitability of lightDM as a KDM replacement. However, I just wanted to point to a couple of discussions about this from gnome-land (as one of the aims was to be cross-desktop)[1,2]. As to power management: I never quite understood why the power management policy daemons are implemented inside the DE's. Shouldn't this be a system-wide daemon, that could be controlled from the DE's (similarly to what Network Manager is for networking)? This would give reasonable power management also when logged in from the console, or as your example illustrates, not logged in at all (at the console or in the DM). Cheers, Tom [1] http://mjg59.dreamwidth.org/2414.html [2] http://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00261.html
Re: KDM plans and lightDM
On Mon, 13 Jun 2011 16:29:45 -0400, Shaun Reich wrote: lightDM is also headed by my dear friend Canonical, as is clearly seen. Serious question: does anyone know if it requires Canonical's copyright assignment to contribute to lightDM? If yes we can stop any further discussion right here IMHO. 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.
Re: KDM plans and lightDM
On Mon, Jun 13, 2011 at 2:55 PM, Alex Fiestas wrote: > On Monday, June 13, 2011 04:46:12 PM Shaun Reich wrote: >> Duh. You've got to be joking. Okay, how about you read up on the >> subject..like uhm...in my blog, before criticizing what you clearly >> are clueless about? >> Blink excessively? You're right, I'll get right on that. > Dude moderate your tone, not everybody knows about everything, I'm asking > about this clueless as you say, but know what? this is for what community is > for, to help each other and share knowlege. > > So, relax. > Thanks. I apologize for the tone I used. I just can't help myself from getting upset when I see unneeded duplication. Especially since I've seen it first-hand too many times. -- Shaun Reich, KDE Software Developer (kde.org)
Re: KDM plans and lightDM
On Mon, Jun 13, 2011 at 6:03 PM, Thomas Lübking wrote: > Am Mon, 13 Jun 2011 16:46:12 -0400 > schrieb Shaun Reich : > > Sorry, I don't read your blog - just did a quick google and thought this > was the best place to get a reliable answer. No problem. Just don't try to critique something until at least reading up on it (which someone else linked to previously in the thread, even). > OFF TOPIC --snip > "From a clock, battery monitor, the kdm greeter (of course. you know, > the login dialog), system monitors, disc usage, sticky notes, > calculator, on-screen keyboard" > > You got a better link why else using plasma is great? Huh? Other than the fact that it is capable of powering an entire workspace on many form factors. > Oh, and did you see "on-screen keyboard"? Again..huh? I really don't know what you're trying to get at with this. The point is we get all of that for free. Whereas if you do not use the whole of Plasma, you have to do it all yourself (take a look at kdm's kfrontend code which creates a clock and such. Just makes things easier when there's zero duplication. > You mean, like compared to the current indirect qwidget -> subclass -> > plasma -> > -> svg > -> (incomplete) qstyle usage ..? > > which usually fails (used to?, actually not tried lately) if you deviate > from oxygen's margins & paddings because it (implicitly) uses (used? no > idea whether this has ever been fixed) the style to calculate the size > but the theme paddings to render clipped strings? > /OFF TOPIC > Sorry, can't comment on this as I've no idea what you're referring to. > This is not what i'm talking about. A "hostile" area is where many ppl. > have (in doubt non physical) access to the same machine. > So if user x can get user y to add a malicious plasmoid to the DM > frontend, he can pot. scam his login data/password and use that later > on. The same can be done using kdm's authentication plugins. I could go and make my own right now to do just that, and if the user has root access and installs it, that's the (stupid) user's prerogative. Just like installing any other application on a desktop could do the *very* same. This is of course, coming from the perspective that the user is a system admin. You are aware that in order to add applets to the greeter (if that option is enabled, per system admin), you need to authenticate as root (which is presumably what the system admin only would have). So please don't think this is "anyone who walks by can go and monkey around with it". It sounds like that's what you're confusing it as. > Ahhh... security by opt-out. Of course, because anything else > would render the system pointless in the first place. Once again, you're backwards. YOU NEED ROOT ACCESS TO ADD APPLETS. I just want to emphasize that. The "the sysadmin can disable that" was referring to a button, a la what the cashew has, to unlock widgets and be able to add them. To do that..once again, *requires root access*. I was simply referring to visually disabling it. It still wouldn't be functional without root access either way, out of the box. Sorry, but I don't think you read my blog entries thoroughly enough. Just as using a utility without reading the man page can destroy your system, so can replying to a mailing list without having at least read up on existing docs ;-p > Overlay the input fields? > Scam logins & passwords? > Maybe just hook on textChanged signals for that purpose? See above. The same *exact* thing could be done if someone just installed a custom PAM authentication. Seriously. What do you expect if the user has root access, is able to install anything he wants, and installs a malicious piece of software? Are you entirely unaware of how malware works? Malware plays upon the users stupidity with elevated privileges. If you never elevate the privileges, what's going to happen? Well. The software wouldn't be installed, for one. I really think you are thinking incorrectly. This situation can be applied to ANYTHING. Give full access to someone and they had better know what they are doing, because if they are stupid enough to install compromising software on their system -- then their system just got compromised. That's the fundamental flaw in any security model: the user who has root access. (think that covers everything in this thread..onto the next, hehe) -- Shaun Reich, KDE Software Developer (kde.org)
Re: KDM plans and lightDM
Am Tue, 14 Jun 2011 00:02:02 +0200 schrieb Alex Fiestas : > splashy replacement), though I know that KDM without patches doesn't > have a smooth transition. Ah, ok - that part wasn't about power savings at all ;-) > There is a patch from the Fedora team that Got a link? (it probably grabs the framebuffer before changing to X and fades it out?) > won't be applied into KDM because it is crappy (ossi says). Ossi's usually right ;-) Did he explain why as well? > GDM loads the "gnome power management" to solve the issue, Actually it loads half a gnome session... > does? can KDM maybe launch kded with some daemons? i think (iff one wants this in the DM frontend) this would be overheaded. Since the DM greeter is the only interface receiving input events, it can just trigger UPower (or the solid wrapper) directly. Cheers, Thomas
Re: KDM plans and lightDM
Am Mon, 13 Jun 2011 16:46:12 -0400 schrieb Shaun Reich : > Of course *a*. I even went out of my way to specify it in other blog > entries, multiple times iirc. Sorry, I don't read your blog - just did a quick google and thought this was the best place to get a reliable answer. OFF TOPIC > It isn't just about the look. Other quick google up. http://sreich.blogspot.com/2010/01/kdm-and-plasma-future.html "using the same theming system" "Line edits, button mouseover, click events and more, will all look nice and at home with the rest of the system" "Wallpapers will be fun also." "From a clock, battery monitor, the kdm greeter (of course. you know, the login dialog), system monitors, disc usage, sticky notes, calculator, on-screen keyboard" You got a better link why else using plasma is great? Oh, and did you see "on-screen keyboard"? > But you have fun with implementing that. > I'd love to know how flexible and clean the code is You mean, like compared to the current indirect qwidget -> subclass -> plasma -> -> svg -> (incomplete) qstyle usage ..? which usually fails (used to?, actually not tried lately) if you deviate from oxygen's margins & paddings because it (implicitly) uses (used? no idea whether this has ever been fixed) the style to calculate the size but the theme paddings to render clipped strings? /OFF TOPIC > A "hostile" environment? If they have access to your PC you're screwed This is not what i'm talking about. A "hostile" area is where many ppl. have (in doubt non physical) access to the same machine. So if user x can get user y to add a malicious plasmoid to the DM frontend, he can pot. scam his login data/password and use that later on. Especially the KDM frontend is not the best location for permission leverage attempts. > The sysadmin would easily be able to prevent any additional plasmoids > from being added. Ahhh... security by opt-out. Of course, because anything else would render the system pointless in the first place. I however don't worry about professionally administrated systems at all (because such things rather won't show up there, by no means) but the small-to-mid (or just badly) semi administrated stuff (which is apparently the core audience for this as well) - maybe run a query on kde-apps on who uses or even knows about kiosk. > Not only that, the applets only run as user. I did not expect the foreground process on root permissions anyway. > So if the sysadmin did not disable that, and the user can add > them...tell me..what are they going to do? Overlay the input fields? Scam logins & passwords? Maybe just hook on textChanged signals for that purpose? I haven't read the code, so i frankly don't know what kind of security levels you've added to prevent such, but it is dangerous (as mentioned: not in the meaning of leverage, but information gathering) And really, since the DM greeter is a 3 second "see, type, enter" thing, I wonder why anybody should add any kind of risk level for some stupid custom clock there. Maybe i'm just too old now, but i do really not see the least reason for that at all. Cheers, Thomas
Re: KDM plans and lightDM
On Monday, June 13, 2011 10:24:22 PM Thomas Lübking wrote: > Am Mon, 13 Jun 2011 21:34:56 +0200 > > schrieb Martin Gräßlin : > > What does power management has to do with KDM? This belongs into > > powerdevil where to my knowledge it should be handled fine, if > > configured correctly. > > I guess he means: >"autosuspension from KDM", ie. w/o being logged in at all - he >started the system, didn't log in, talked a lot of meeting nonsense >(tm), legged in - and the battery was sucked away. > >I won't comment on the preferred usage of advanced bioneural cpu to > circumvent such issues in the first place, but this function does imho > not belong into a DM but into some cron job (or whatever other daemon) > that watches how long nobody has been logged in and *whether no relevant > daemon is running* and then suspend the system after some time. I don't really know what a DM should and should not do, so yes, a cron job should do the work just fine. > This should also cover plymouth (the splashy replacement? really?) - > but if you mean "bash", you'll require the feature (watching > keystrokes) there, i think. > >Putting this into a DM is rather bad because there's no good default* > and it's not a DM's job to watch other processes (while maybe other > logins...) and manage some random blacklist on them. I'm not sure what's needed to integrate a DM with plymouth (the splashy replacement), though I know that KDM without patches doesn't have a smooth transition. There is a patch from the Fedora team that won't be applied into KDM because it is crappy (ossi says). > *you do not want to suspend your system because you didn't log in since > (despite starting to runlevel 5...) there's currently some sshd up and > you're logged into from somewhere else, or just because the machine runs > a webserver as well... The 95% of desktop users doesn't use either sshd or a webserver. So at least this should be configurable. GDM loads the "gnome power management" to solve the issue, what KDM does? can KDM maybe launch kded with some daemons? It may no be perfect but lightDM at least does some handling directly talking to UPower, though I agree that DM is not the place to fix this issue.
Re: KDM plans and lightDM
On Monday, June 13, 2011 09:01:06 PM John Layt wrote: > On Monday 13 Jun 2011 20:34:56 Martin Gräßlin wrote: > > What does power management has to do with KDM? This belongs into > > powerdevil where to my knowledge it should be handled fine, if > > configured correctly. > > Not sure, but I wonder if Alex means he wasn't logged in so powerdevil > couldn't work? Exactly. > > Rhethorical question: how can it be "cross-desktop" if KDE has not been > > involved in the development effort so far? Who is the "cross-desktop", > > who is behind it? > > It seems quite fashionable to start a project on freedesktop.org without > involving KDE and to build it using Gnome tech, then ask us to use it > because "it's a cross-desktop project". How are they supposed to know what > our requirements are without asking us? What are the criteria for getting > fd.o hosting/blessing these days? > > Note I don't know if this is the case for this project, I haven't heard > anything about it before, but I may not be on the right lists. > Enlightenment gratefully received. Well, David Edmundson is working on a Qt/KDE greeter, so far it has support for QML and is looking good.
Re: KDM plans and lightDM
On Mon, Jun 13, 2011 at 4:24 PM, Thomas Lübking wrote: > > Semi-OT: >> knowledge there is some work going on to bring a Plasma interface to >> KDM which would be a very unique feature. > > This? > http://sreich.blogspot.com/2010/06/kdm-plasma-update.html > > Errr... hopefully *a* - and not *the* kdm frontend. Of course *a*. I even went out of my way to specify it in other blog entries, multiple times iirc. I guess I should implement a big blinking marquee for the impaired as well as for the ones who can't read. > If it's just about the look: > move the plasma frame rendering stuff to kdeui. done. > I'd write you a plasmatic general UI style to prevent this ;-) It isn't just about the look. But you have fun with implementing that. I'd love to know how flexible and clean the code is > But allowing "random" scripts in a login manager is like asking > people to shoot themself. See "plasmoids" bit, further below... > Sorry for being rough now, but that is really a braindead idea and > at best acceptable for the single user desktop (ie. the ppl. who > probably use autologin anyway), but certainly *not* in a hostile > environment. A "hostile" environment? If they have access to your PC you're screwed anyways. Anything less than hostile is what any login manager would be providing for. Nothing more. If you're trying to prevent total access to your computer from non-average users, then you're fucked regardless of what method you use. > But plasmoids are really the opposite of "secure" - you'd have to tell > everybody to carefully inspect the plasmoids tehy want to put into the > DM, or provide a database of trustworthy ones and who's gonna do that? Duh. You've got to be joking. Okay, how about you read up on the subject..like uhm...in my blog, before criticizing what you clearly are clueless about? The sysadmin would easily be able to prevent any additional plasmoids from being added. That's built into Plasma's kiosk abilities. Oh but you knew that before responding, because you know all about this subject, or have at least half-ass read up on it. I see. Not only that, the applets only run as user. So if the sysadmin did not disable that, and the user can add them...tell me..what are they going to do? Blink excessively? You're right, I'll get right on that. -- Shaun Reich, KDE Software Developer (kde.org)
Re: KDM plans and lightDM
> It seems quite fashionable to start a project on freedesktop.org without > involving KDE and to build it using Gnome tech, then ask us to use it because > "it's a cross-desktop project". Oh yes. Apparently it's better than KDM because it's very cross-desktopy. And better. And stuff. Whatever the hell that means. And it doesn't depend on any toolkit except glib!! Which, KDM has had since the beginning with it's separation between backend and frontends. lightDM is also headed by my dear friend Canonical, as is clearly seen. Of note is that ldm uses d-bus, whereas kdm uses sockets. So as for the "lightweight" part, they just forced everyone to have a full dbus session up. Instead of working with existing code, *apparently* it is more effective to make a new project altogether. I think we should adopt this strategy. After all, isn't KDELibs and KIO getting really old and crappy? Time to rm -Rf / and start from scratch... Oh wait. The *same exact* situation was presented to us with GIO. "create something new, disregard existing implementations, force adoption after everything is finalized." Well, so I guess that base is already covered..lets find another one. Evidently age is indicative not of stability or refinement, but of a dying animal, ready to be put down. mjg95's blog entry hits the nail on the head. I also laugh out loud at how the project brags about having "much, much less code than $kdm/gdm". But what do you think the code was there for? Did we have 50,000 lines of code accidentally copied somewhere? I think not. I'm pretty sure it's self-evident that the code actually *serves* a purpose. Purposes that LightDM still has marked as "well...we don't *quite* have that juuusssttt yet". But hey, my powers of observation must be astounding. -- Shaun Reich, KDE Software Developer (kde.org)
Re: KDM plans and lightDM
Am Mon, 13 Jun 2011 21:34:56 +0200 schrieb Martin Gräßlin : > What does power management has to do with KDM? This belongs into > powerdevil where to my knowledge it should be handled fine, if > configured correctly. I guess he means: "autosuspension from KDM", ie. w/o being logged in at all - he started the system, didn't log in, talked a lot of meeting nonsense (tm), legged in - and the battery was sucked away. I won't comment on the preferred usage of advanced bioneural cpu to circumvent such issues in the first place, but this function does imho not belong into a DM but into some cron job (or whatever other daemon) that watches how long nobody has been logged in and *whether no relevant daemon is running* and then suspend the system after some time. This should also cover plymouth (the splashy replacement? really?) - but if you mean "bash", you'll require the feature (watching keystrokes) there, i think. Putting this into a DM is rather bad because there's no good default* and it's not a DM's job to watch other processes (while maybe other logins...) and manage some random blacklist on them. *you do not want to suspend your system because you didn't log in since (despite starting to runlevel 5...) there's currently some sshd up and you're logged into from somewhere else, or just because the machine runs a webserver as well... > > Also, since the last Ubuntu Development Summit I started to look > > into lightDM[1] Try Quingy! anybody anything else? Semi-OT: > knowledge there is some work going on to bring a Plasma interface to > KDM which would be a very unique feature. This? http://sreich.blogspot.com/2010/06/kdm-plasma-update.html Errr... hopefully *a* - and not *the* kdm frontend. If it's just about the look: move the plasma frame rendering stuff to kdeui. done. I'd write you a plasmatic general UI style to prevent this ;-) But allowing "random" scripts in a login manager is like asking people to shoot themself. Sorry for being rough now, but that is really a braindead idea and at best acceptable for the single user desktop (ie. the ppl. who probably use autologin anyway), but certainly *not* in a hostile environment. Really not. The purpose of the login manager is to allow reliable and secure login. That's it. If it's cute on top: nice. But plasmoids are really the opposite of "secure" - you'd have to tell everybody to carefully inspect the plasmoids tehy want to put into the DM, or provide a database of trustworthy ones and who's gonna do that? Cheers, Thomas
Re: KDM plans and lightDM
On Monday 13 Jun 2011 20:34:56 Martin Gräßlin wrote: > What does power management has to do with KDM? This belongs into powerdevil > where to my knowledge it should be handled fine, if configured correctly. Not sure, but I wonder if Alex means he wasn't logged in so powerdevil couldn't work? > Rhethorical question: how can it be "cross-desktop" if KDE has not been > involved in the development effort so far? Who is the "cross-desktop", who > is behind it? It seems quite fashionable to start a project on freedesktop.org without involving KDE and to build it using Gnome tech, then ask us to use it because "it's a cross-desktop project". How are they supposed to know what our requirements are without asking us? What are the criteria for getting fd.o hosting/blessing these days? Note I don't know if this is the case for this project, I haven't heard anything about it before, but I may not be on the right lists. Enlightenment gratefully received.
Re: KDM plans and lightDM
Martin Gräßlin wrote: > On Monday 13 June 2011 21:10:36 Alex Fiestas wrote: > > Also, since the last Ubuntu Development Summit I started to look into > > lightDM[1] as a possible alternative (at least for my use), I event > > managed to patch kdisplaymanager.cpp to play nice with it. > > To me the question is: what does lightDM offer what KDM does not provide? http://mjg59.livejournal.com/136274.html Eike signature.asc Description: This is a digitally signed message part.
Re: KDM plans and lightDM
On Monday 13 June 2011 21:10:36 Alex Fiestas wrote: > Hi there > > Today something happened to me again, I turn on my laptop at the begining of > a > meeting and when I needed it the battery was over because the laptop didn't > went to suspension (as I'm used). > > That makes me wonder what are the plans for KDM in this and other regards > since I haven't seen much activity on it (apart from bugfixing). What does power management has to do with KDM? This belongs into powerdevil where to my knowledge it should be handled fine, if configured correctly. Btw. I consider it as a very good thing that KDM does not require any more changes than bugfixing. I think it is extremly important to have a rock solid DM. > > Also, since the last Ubuntu Development Summit I started to look into > lightDM[1] as a possible alternative (at least for my use), I event managed > to > patch kdisplaymanager.cpp to play nice with it. To me the question is: what does lightDM offer what KDM does not provide? If it does not have any new cool feature impossible to add to KDM I would vote for "don't fix what is not broken". KDM has served us very well over the last years and I think it is one of our best products in the workspace. > > I'm not an expert on Display Managers so I can't really tell if lightDM is > good enough (or will be good enough) to replace KDM. When I asked to some > distribution people the first thing they told me is: "Does it support XDMCP?" > and I don't know even what XDMCP is... > > So, what are the plans for KDM? can we expect some power management > integration? and plymouth? I don't see what power management and plymouth have to do with KDM. Power managmeent is after KDM and plymouth is before KDM. To my knowledge there is some work going on to bring a Plasma interface to KDM which would be a very unique feature. We will also have to do some work to bring Wayland support to KDM. I do not have an idea on how to do it, but it's one of the big issues (btw also for lightDM). > > For the experts: Does lightDM feel nice as a cross-desktop solution? is it > good enough? Rhethorical question: how can it be "cross-desktop" if KDE has not been involved in the development effort so far? Who is the "cross-desktop", who is behind it? I have no idea what lightDM provides and what not, but I am very sceptical about changing this important part of our workspace offerings. We are just at the edge to transit to another windowing system which will require changes in the DM area, so if lightDM supports Wayland it makes sense to consider it as an option. If it does not, we should better stick to what we have for X11 in order to not change the DM twice in a short time. We also have to keep in mind that even when we transit to Wayland as our default we will also have to offer an X11 solution. For me it is clear that users should not notice a difference whether they use X11 or Wayland - also in the login manager. Kind Regards Martin signature.asc Description: This is a digitally signed message part.
