FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 05-17-2011, 11:38 PM
Scott Kitterman
 
Default LightDM-KDE

On Tuesday, May 17, 2011 07:06:47 PM David Edmundson wrote:
> Robert Ancell (the main LightDM guy) has been refactoring the backend,
> which has led to some changes in the Qt lib which I'm not 100% happy with.
> Instead of just jumping on dbus, we now have a lot of GTK lib
> copying+pasting with a thin Qt wrapper in the main class of the greeter.
> At a minimum I want this moved out to a separate private class to give a
> very clean maintainable header to the publicly exposed main lib. Ideally
> we'd want someone like George Kiagiadis involved who is extremely pro at
> auto-building Qt bindings for GTK and get a library that isn't going to
> fall apart as soon as the GTK version updates.

This sounds like a strong candidate for a deal breaker to me.

Scott K

P.S. We weren't considering Light DM until Ubuntu decided to switch and so we
scheduled something rater last minute to discuss it as best we could.

Scott K

--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 05-17-2011, 11:56 PM
David Edmundson
 
Default LightDM-KDE

On Wed, May 18, 2011 at 12:26 AM, Harald Sitter <sitter.harald@gmail.com> wrote:

Hi David,



On Wed, May 18, 2011 at 1:06 AM, David Edmundson

<david@davidedmundson.co.uk> wrote:

> I stumbled upon your blueprint plans for use of LightDM in Kubuntu 11.10,

> and as the person who has written most of LightDM-qt so far I wanted to add

> some opinions and an update on where the lib is.

> Firstly if you're going to discuss LightMD, it would have been nice to have

> been notified.



We did not even know you were working on it (well, at least I did not

). The plan itself is to carry the whole discussion and

implementation upstream to KDE, and see if KDM is a lost cause and if

it is whether people are in favor of going with LightDM. At least then

you would have known of the discussion I assume. At any rate not

inviting you to the UDS discussion was by no means intentional.


Sorry, that came across really whiny - it wasn't intended.
I have been at the pub, I'm going to blame it on that.*

> There's so much I intend to get done with it,*but I've been really busy

> trying to get KDE Telepathy out. It's all already consuming far more time

> than I really should let it.

> Anyway. What's the current state and what needs to be done:

> Robert Ancell (the main LightDM guy) has ,been refactoring the backend, which

> has led to some changes in the Qt lib which I'm not 100% happy with. Instead

> of just jumping on dbus, we now have a lot of GTK lib copying+pasting with a

> thin Qt wrapper in the main class of the greeter. At a minimum I want this

> moved out to a*separate private*class to give a very clean maintainable

> header to the*publicly*exposed main lib. Ideally we'd want someone like

> George Kiagiadis involved who is extremely pro at auto-building Qt bindings

> for GTK and get a library that isn't going to fall apart as soon as the GTK

> version updates.



Selling a GTK+ dependency to people will be *very* difficult, so I

think DBus is the better choice really.


My bad, I worded that very badly. It's copied and pasted native C code, that is then either bound to GTK in the GTK lib, or Qt in ours.*There's no lib-dependency.
The point is that it's copied and pasted code. That's never a long term good sign. We don't want the two going out of sync.
It does seem like the LightDM backend suddenly lost it's DBus interface and I'm not sure why.*




> I have a far better demo greeter on kde's git repo than the one in bzr repo.

> I'll try and merge that.

> I want to give it a really significant refactor that switches the lists of

> LdmSessions, LdmUsers, and Langauges to be Qt models. *I also want to expose

> the power management parts as Q_PROPERTIES.**I did start this a while ago,

> it's not finished but if I worked on it, I could get it done.*This not only

> makes GUI's quite a bit quicker to build, but will make plasma bindings very

> easy.



Also necessary for QML, so definitely worth the effort.



> It was started by me a year ago, and I wasn't as familiar with KDE

> standards/lib consistency as I am now. It's not bad, but it's far from

> perfect.*I would really appreciate it if you could give me a month to

> completely tidy up all the crap up to make it decent ABI stable code.

> As for plasma:

> With my LibLightDm-Qt hat on, I will absolutely support everything you do

> and will do anything I can to make the library really easy for you to use,

> let me know and I'll do what I can to update the lib.

> With my generic developer hat on, using plasma is an ill-thought through

> idea. To me it seems you've jumped to the solution before you've worked out

> what problems you're trying to solve are. I also believe it's a security

> risk, will lead to slow load times and potentially unstable login screens. I

> think it will lead to a lot of future problems. I have an alternate (pure

> QML-oriented) scheme in mind that allows for

> greater*flexibility/theming*with a sensible KCM that I think is pretty

> solid. However I'm not one for arguments, and LightDM does allow for

> multiple greeters (both built off the same greeter lib) really easily so we

> can easily do our own thing.



There were no particular decision set in stone about using Plasma.

Just seemed like an obvious choice. I must say having a QML greeter is

certainly intriguing too, especially since I understand Canonical

wants to invest in a Qt greeter anyway, so we could share resources

there.



What I would like to see is a list of things we want to do with the greeter - and then we can discuss the best solutions for doing it. I'm talking to Alex Fiestas on IRC, I'm not /that/ against plasma, I just want to the right solution chosen properly, not because it's the latest buzzword.

*
BTW, you can listen to the session at [1]



[1] http://mirrors.tumbleweed.org.za/uds-o/2011-05-13-12-55-desktop-o-kubuntu-lightdm.ogg

Will do, Thanks. *
Can I propose that:* - We all get our thinking caps on, come up with ideas for "our ideal login manager" (including the KCM)** - We get some idea from Robert (and anyone else on the main LightDM side) as to what upcoming changes in the backend we can expect.
* - I'll tidy up the library code, and make it both QML and Plamsa ready (pretty much the same thing, more models, more property macros etc.)* - From here we have an IRC meeting to discuss the plan.*




regards,

Harald



--

kubuntu-devel mailing list

kubuntu-devel@lists.ubuntu.com

Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel



--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 05-18-2011, 12:03 AM
Harald Sitter
 
Default LightDM-KDE

On Wed, May 18, 2011 at 1:56 AM, David Edmundson
<david@davidedmundson.co.uk> wrote:
>
>
> On Wed, May 18, 2011 at 12:26 AM, Harald Sitter <sitter.harald@gmail.com>
> wrote:
>>
>> Hi David,
>>
>> On Wed, May 18, 2011 at 1:06 AM, David Edmundson
>> <david@davidedmundson.co.uk> wrote:
>> > There's so much I intend to get done with it,*but I've been really busy
>> > trying to get KDE Telepathy out. It's all already consuming far more
>> > time
>> > than I really should let it.
>> > Anyway. What's the current state and what needs to be done:
>> > Robert Ancell (the main LightDM guy) has ,been refactoring the backend,
>> > which
>> > has led to some changes in the Qt lib which I'm not 100% happy with.
>> > Instead
>> > of just jumping on dbus, we now have a lot of GTK lib copying+pasting
>> > with a
>> > thin Qt wrapper in the main class of the greeter. At a minimum I want
>> > this
>> > moved out to a*separate private*class to give a very clean maintainable
>> > header to the*publicly*exposed main lib. Ideally we'd want someone like
>> > George Kiagiadis involved who is extremely pro at auto-building Qt
>> > bindings
>> > for GTK and get a library that isn't going to fall apart as soon as the
>> > GTK
>> > version updates.
>>
>> Selling a GTK+ dependency to people will be *very* difficult, so I
>> think DBus is the better choice really.
>
>
> My bad, I worded that very badly. It's copied and pasted native C code, that
> is then either bound to GTK in the GTK lib, or Qt in ours.*There's no
> lib-dependency.
> The point is that it's copied and pasted code. That's never a long term good
> sign. We don't want the two going out of sync.

Oh, yeah, that is absolutely good.

> It does seem like the LightDM backend suddenly lost it's DBus interface and
> I'm not sure why.

This is not so good :S

>> There were no particular decision set in stone about using Plasma.
>> Just seemed like an obvious choice. I must say having a QML greeter is
>> certainly intriguing too, especially since I understand Canonical
>> wants to invest in a Qt greeter anyway, so we could share resources
>> there.
>>
>
> What I would like to see is a list of things we want to do with the greeter
> - and then we can discuss the best solutions for doing it. I'm talking to
> Alex Fiestas on IRC, I'm not /that/ against plasma, I just want to the right
> solution chosen properly, not because it's the latest buzzword.

Sane technical decisions FTW.

requirements that come to mind:
* must be able to support finger print auth stuff
* must be able to support face detection auth stuff
Both from a GUI POV of course.

>> BTW, you can listen to the session at [1]
>>
>> [1]
>> http://mirrors.tumbleweed.org.za/uds-o/2011-05-13-12-55-desktop-o-kubuntu-lightdm.ogg
>
> Will do, Thanks.
> Can I propose that:
> * - We all get our thinking caps on, come up with ideas for "our ideal login
> manager" (including the KCM)
> * - We get some idea from Robert (and anyone else on the main LightDM side)
> as to what upcoming changes in the backend we can expect.
> * - I'll tidy up the library code, and make it both QML and Plamsa ready
> (pretty much the same thing, more models, more property macros etc.)
> * - From here we have an IRC meeting to discuss the plan.

- Discuss stuff upstream and with other distros

Sounds like a plan!

regards,
Harald

--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 05-18-2011, 12:10 AM
"Alex Fiestas"
 
Default LightDM-KDE

On Wed, 18 May 2011 02:03:43 +0200, Harald Sitter
<sitter.harald@gmail.com> wrote:

requirements that come to mind:
* must be able to support finger print auth stuff
* must be able to support face detection auth stuff
Both from a GUI POV of course.
KDM doesn't support that features right now... I don't see then why
they're a "msut" :/


For me, we should focus on having the KDM features first, and then
accessibility.


BTW, I'm not sure where I put my thinking cap... will try to think about
it xD


--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 05-18-2011, 12:16 AM
Harald Sitter
 
Default LightDM-KDE

On Wed, May 18, 2011 at 2:10 AM, Alex Fiestas <afiestas@kde.org> wrote:
> On Wed, 18 May 2011 02:03:43 +0200, Harald Sitter <sitter.harald@gmail.com>
> wrote:
>>
>> requirements that come to mind:
>> * must be able to support finger print auth stuff
>> * must be able to support face detection auth stuff
>> Both from a GUI POV of course.
>
> KDM doesn't support that features right now... I don't see then why they're
> a "msut" :/

I did not say it must provide them itself (not in first release
anyway), it must allow for them, meaning we should keep them in mind.
The better we understand the requirements for a modern DM, the easier
it gets to create one IMHO.

Besides, KDM supports just about anything PAM supports, but visually
you can only achieve it in a very crappy way AFAIK.

> For me, we should focus on having the KDM features first, and then
> accessibility.

No argument there.

regards,
Harald

--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 05-18-2011, 01:36 AM
Robert Ancell
 
Default LightDM-KDE

Hi David,

Sorry for not notifying you of the session. It was scheduled very late
(i.e. just after the main LightDM session on Thursday) and I ended up
being sick on Friday so it wasn't running at 100%.

Regarding the D-Bus interface to the daemon - originally there was not
going to be any client libraries - the interface would be all D-Bus to
the daemon. The client libraries were added to make this interface
easier to use; then they had additional functionality added; then they
got to the point where so little of the communication was to the daemon,
and securing that communication through a pipe rather than using D-Bus
for convenience became more important.

There are two libraries, a GLib based one (no GTK dependency), and the
Qt one. Yes, they contain the same functionality, which has some
overhead. However, wrapping the GLib one would lead to an API that
doesn't feel Qt (as far as I know - I'm quite new to Qt). I'm
completely happy to support both GLib and Qt to the same level (i.e. Qt
is a first class citizen here), and both these libraries will be fully
unit-tested.

We'll almost certainly use a Qt based greeter for Ubuntu for Unity 2D,
and this will be a fallback greeter when using the Unity 3D greeter.
I'm not sure how KDE does fallback or detects if it can't use Plasma but
this may be a solution for KDE too.

--Robert

On 05/18/2011 01:06 AM, David Edmundson wrote:
> Hey all,
>
> I stumbled upon your blueprint plans for use of LightDM in Kubuntu
> 11.10, and as the person who has written most of LightDM-qt so far I
> wanted to add some opinions and an update on where the lib is.
>
> Firstly if you're going to discuss LightMD, it would have been nice to
> have been notified.
> There's so much I intend to get done with it, but I've been really
> busy trying to get KDE Telepathy out. It's all already consuming far
> more time than I really should let it.
>
> Anyway. What's the current state and what needs to be done:
>
> Robert Ancell (the main LightDM guy) has been refactoring the backend,
> which has led to some changes in the Qt lib which I'm not 100% happy
> with. Instead of just jumping on dbus, we now have a lot of GTK lib
> copying+pasting with a thin Qt wrapper in the main class of the
> greeter. At a minimum I want this moved out to a separate
> private class to give a very clean maintainable header to
> the publicly exposed main lib. Ideally we'd want someone like George
> Kiagiadis involved who is extremely pro at auto-building Qt bindings
> for GTK and get a library that isn't going to fall apart as soon as
> the GTK version updates.
>
> I have a far better demo greeter on kde's git repo than the one in bzr
> repo. I'll try and merge that.
>
> I want to give it a really significant refactor that switches the
> lists of LdmSessions, LdmUsers, and Langauges to be Qt models. I also
> want to expose the power management parts as Q_PROPERTIES. I did
> start this a while ago, it's not finished but if I worked on it, I
> could get it done. This not only makes GUI's quite a bit quicker to
> build, but will make plasma bindings very easy.
>
> It was started by me a year ago, and I wasn't as familiar with KDE
> standards/lib consistency as I am now. It's not bad, but it's far from
> perfect. I would really appreciate it if you could give me a month to
> completely tidy up all the crap up to make it decent ABI stable code.
>
> As for plasma:
> With my LibLightDm-Qt hat on, I will absolutely support everything you
> do and will do anything I can to make the library really easy for you
> to use, let me know and I'll do what I can to update the lib.
>
> With my generic developer hat on, using plasma is an ill-thought
> through idea. To me it seems you've jumped to the solution before
> you've worked out what problems you're trying to solve are. I also
> believe it's a security risk, will lead to slow load times and
> potentially unstable login screens. I think it will lead to a lot of
> future problems. I have an alternate (pure QML-oriented) scheme in
> mind that allows for greater flexibility/theming with a sensible KCM
> that I think is pretty solid. However I'm not one for arguments, and
> LightDM does allow for multiple greeters (both built off the same
> greeter lib) really easily so we can easily do our own thing.
>
> Regards
>
> David Edmundson
>
>


--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 05-19-2011, 08:49 AM
David Edmundson
 
Default LightDM-KDE

On Wed, May 18, 2011 at 2:36 AM, Robert Ancell <robert.ancell@canonical.com> wrote:


Hi David,



Sorry for not notifying you of the session. *It was scheduled very late

(i.e. just after the main LightDM session on Thursday) and I ended up

being sick on Friday so it wasn't running at 100%.

Sorry to hear that, hope you get well soon.*




Regarding the D-Bus interface to the daemon - originally there was not

going to be any client libraries - the interface would be all D-Bus to

the daemon. *The client libraries were added to make this interface

easier to use; then they had additional functionality added; then they

got to the point where so little of the communication was to the daemon,

and securing that communication through a pipe rather than using D-Bus

for convenience became more important.



There are two libraries, a GLib based one (no GTK dependency), and the

Qt one. *Yes, they contain the same functionality, which has some

overhead. *However, wrapping the GLib one would lead to an API that

doesn't feel Qt (as far as I know - I'm quite new to Qt). *I'm

completely happy to support both GLib and Qt to the same level (i.e. Qt

is a first class citizen here), and both these libraries will be fully

unit-tested.


We do sometimes wrap glib ones for example QtGstreamer, whereas othertimes it's all new code pulling data from Dbus (such as Telepathy-Qt). Sometimes (such as in Qt Core) functionality is written from scratch using the relevant native APIs. So there's no "standard'.


What I'm concerned about is when you add extra functionality (for example Grub reboot OS selection) into one of the library it has to be written out in both - and we have the potential to have bugs in one and not in the other. It will be hard to sort out bug reports when we have two client libraries potentially doing different things - especially when the bug report doesn't indicate which library is being used.*


If we are treating them as first class citizens (which so far has been the case, thanks ever so much for updating the Qt libs) then maybe this isn't a problem :-)*---


KDE people there is a slightly nicer Qt demo greeter here:*git://anongit.kde.org/scratch/davidedmundson/kde-greeter.git*Still purely demo-ish code to test the lib.


Robert - are you happy for the Qt demo greeter to have KDE code/dependencies, or do you want to keep it Qt only?




We'll almost certainly use a Qt based greeter for Ubuntu for Unity 2D,

and this will be a fallback greeter when using the Unity 3D greeter.

I'm not sure how KDE does fallback or detects if it can't use Plasma but

this may be a solution for KDE too.


--Robert



On 05/18/2011 01:06 AM, David Edmundson wrote:

> Hey all,

>

> I stumbled upon your blueprint plans for use of LightDM in Kubuntu

> 11.10, and as the person who has written most of LightDM-qt so far I

> wanted to add some opinions and an update on where the lib is.

>

> Firstly if you're going to discuss LightMD, it would have been nice to

> have been notified.

> There's so much I intend to get done with it, but I've been really

> busy trying to get KDE Telepathy out. It's all already consuming far

> more time than I really should let it.

>

> Anyway. What's the current state and what needs to be done:

>

> Robert Ancell (the main LightDM guy) has been refactoring the backend,

> which has led to some changes in the Qt lib which I'm not 100% happy

> with. Instead of just jumping on dbus, we now have a lot of GTK lib

> copying+pasting with a thin Qt wrapper in the main class of the

> greeter. At a minimum I want this moved out to a separate

> private class to give a very clean maintainable header to

> the publicly exposed main lib. Ideally we'd want someone like George

> Kiagiadis involved who is extremely pro at auto-building Qt bindings

> for GTK and get a library that isn't going to fall apart as soon as

> the GTK version updates.

>

> I have a far better demo greeter on kde's git repo than the one in bzr

> repo. I'll try and merge that.

>

> I want to give it a really significant refactor that switches the

> lists of LdmSessions, LdmUsers, and Langauges to be Qt models. *I also

> want to expose the power management parts as Q_PROPERTIES. *I did

> start this a while ago, it's not finished but if I worked on it, I

> could get it done. This not only makes GUI's quite a bit quicker to

> build, but will make plasma bindings very easy.

>

> It was started by me a year ago, and I wasn't as familiar with KDE

> standards/lib consistency as I am now. It's not bad, but it's far from

> perfect. I would really appreciate it if you could give me a month to

> completely tidy up all the crap up to make it decent ABI stable code.

>

> As for plasma:

> With my LibLightDm-Qt hat on, I will absolutely support everything you

> do and will do anything I can to make the library really easy for you

> to use, let me know and I'll do what I can to update the lib.

>

> With my generic developer hat on, using plasma is an ill-thought

> through idea. To me it seems you've jumped to the solution before

> you've worked out what problems you're trying to solve are. I also

> believe it's a security risk, will lead to slow load times and

> potentially unstable login screens. I think it will lead to a lot of

> future problems. I have an alternate (pure QML-oriented) scheme in

> mind that allows for greater flexibility/theming with a sensible KCM

> that I think is pretty solid. However I'm not one for arguments, and

> LightDM does allow for multiple greeters (both built off the same

> greeter lib) really easily so we can easily do our own thing.

>

> Regards

>

> David Edmundson

>

>





--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 06-09-2011, 07:57 PM
David Edmundson
 
Default LightDM-KDE

Hey all,

I wanted to give a bit of an update about QLightDM (what I've called
the Qt library for LightDM Greeters), as well as the direction I want
to take the KDE side.

The library is much better than it was a few weeks ago. It still has
quite a few missing features, and still a few bits I don't like, but
it's pretty good, and quite easy to use.

For the KDE side of things I intend to have a QML powered greeter
engine. This will display any QML file as the greeter, and provide all
the linking to the LightDM daemon and general models and such.

This enables anyone to build a login theme without any compiling, and
makes it completely safe for the end user.
I've outlined my goals/design/reasoning in more detail here:
http://static.davidedmundson.co.uk/lightdm_goals.txt

There is also a shiny picture of what my demo greeter looks like here:
http://static.davidedmundson.co.uk/lightdm_2.png. Note the use of
plasma widgets.
It's not finished, but it shows what I'm doing. I imagine kubuntu will
want to Kubuntu-ify it a bit. If anyone has any designs let me know.

This is in development here:
http://quickgit.kde.org/?p=scratch%2Fdavidedmundson%2Flightdmqmlgreeter.gi t&a=summary
There is a demo theme here:
http://quickgit.kde.org/?p=scratch%2Fdavidedmundson%2Flightdmdemogreeter.g it&a=summary

It requires the latest master of lightdm to compile (lp:lightdm).

I've made a bit of a start on the KDM settings module, but I don't
know any policyKit so will get stuck with that shortly. I'm working on
kde's git repos as I want this to be an upstream thing, though the
general feedback on my blog was fairly negative so I've not approached
anyone yet.

Moving forwards, I think I should take discussion about KDE and
LightDM off the kubuntu ML and maybe onto the LightDM ML? I'm not sure
if I'm bugging people. I also need some opinions from you and to get
some more people on board.

Dave

--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 06-10-2011, 01:19 AM
Harald Sitter
 
Default LightDM-KDE

On Thursday 09 June 2011 20:57:04 David Edmundson wrote:
> For the KDE side of things I intend to have a QML powered greeter
> engine. This will display any QML file as the greeter, and provide all
> the linking to the LightDM daemon and general models and such.
>
> This enables anyone to build a login theme without any compiling, and
> makes it completely safe for the end user.
> I've outlined my goals/design/reasoning in more detail here:
> http://static.davidedmundson.co.uk/lightdm_goals.txt

Sounds awesome.
I'd like to propose two goals though:
a) accessible
b) scalibility (should work well with ldap setups with >10 users etc.)

> There is also a shiny picture of what my demo greeter looks like here:
> http://static.davidedmundson.co.uk/lightdm_2.png. Note the use of
> plasma widgets.
> It's not finished, but it shows what I'm doing. I imagine kubuntu will
> want to Kubuntu-ify it a bit. If anyone has any designs let me know.

Mockup by sheytan: http://img834.imageshack.us/img834/7461/basegi.jpg
I believe this would be a good default. Something I never liked about the
current KDM default is that you cannot click somewhere to select your user,
but instead had to know your user name *eeek*.
To that extent the user name login box perhaps should be non-editable if you
selected a user and only become editable on click. Just a random thought
though.

> This is in development here:
> http://quickgit.kde.org/?p=scratch%2Fdavidedmundson%2Flightdmqmlgreeter.gi t&
> a=summary There is a demo theme here:
> http://quickgit.kde.org/?p=scratch%2Fdavidedmundson%2Flightdmdemogreeter.g it
> &a=summary
>
> It requires the latest master of lightdm to compile (lp:lightdm).

Could someone get this in a PPA please or perhaps the neon people could get
weekly builds going?

> I've made a bit of a start on the KDM settings module, but I don't
> know any policyKit so will get stuck with that shortly. I'm working on
> kde's git repos as I want this to be an upstream thing, though the
> general feedback on my blog was fairly negative so I've not approached
> anyone yet.

With polkit we can help. I think just about everyone in the programming part
of the team had done polkit at one point or another.

As for the comments: you should beware of how important they are. They neither
reflect common opinion nor particularly technical reasoning (especially the
ones on your post from a quick glance). The only two valuable concerns I
noticed were: supreme PAM support and enterprise readiness. Both things that
should entirely be secured before going anywhere with LightDM IMHO.

> Moving forwards, I think I should take discussion about KDE and
> LightDM off the kubuntu ML and maybe onto the LightDM ML? I'm not sure
> if I'm bugging people. I also need some opinions from you and to get
> some more people on board.

If you feel it makes more sense there... Having stuff here is not particularly
distrubing though, especially since we get free status updates that way :P

What sort of people do you need?

regards,
Harald


--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 06-10-2011, 12:02 PM
David Edmundson
 
Default LightDM-KDE

On Fri, Jun 10, 2011 at 2:19 AM, Harald Sitter <apachelogger@ubuntu.com> wrote:
> On Thursday 09 June 2011 20:57:04 David Edmundson wrote:
>> For the KDE side of things I intend to have a QML powered greeter
>> engine. This will display any QML file as the greeter, and provide all
>> the linking to the LightDM daemon and general models and such.
>>
>> This enables anyone to build a login theme without any compiling, and
>> makes it completely safe for the end user.
>> I've outlined my goals/design/reasoning in more detail here:
>> http://static.davidedmundson.co.uk/lightdm_goals.txt
>
> Sounds awesome.
> I'd like to propose two goals though:
> a) accessible
> b) scalibility (should work well with ldap setups with >10 users etc.)

Completely agreed.

Part b should mostly be being handled by the LightDM daemon (Robert's
part) so if it's good enough for Ubuntu it will work for us.

>
>> There is also a shiny picture of what my demo greeter looks like here:
>> http://static.davidedmundson.co.uk/lightdm_2.png. Note the use of
>> plasma widgets.
>> It's not finished, but it shows what I'm doing. I imagine kubuntu will
>> want to Kubuntu-ify it a bit. If anyone has any designs let me know.
>
> Mockup by sheytan: http://img834.imageshack.us/img834/7461/basegi.jpg
> I believe this would be a good default. Something I never liked about the
> current KDM default is that you cannot click somewhere to select your user,
> but instead had to know your user name *eeek*.
> To that extent the user name login box perhaps should be non-editable if you
> selected a user and only become editable on click. Just a random thought
> though.
>
A users list is next on the agenda. All the stuff is in the library
and engine to do it. Should be done by Tuesday.


>> This is in development here:
>> http://quickgit.kde.org/?p=scratch%2Fdavidedmundson%2Flightdmqmlgreeter.gi t&
>> a=summary There is a demo theme here:
>> http://quickgit.kde.org/?p=scratch%2Fdavidedmundson%2Flightdmdemogreeter.g it
>> &a=summary
>>
>> It requires the latest master of lightdm to compile (lp:lightdm).
>
> Could someone get this in a PPA please or perhaps the neon people could get
> weekly builds going?

Not me, I hate packaging. It's waaaaaaaaaay too difficult.
>
>> I've made a bit of a start on the KDM settings module, but I don't
>> know any policyKit so will get stuck with that shortly. I'm working on
>> kde's git repos as I want this to be an upstream thing, though the
>> general feedback on my blog was fairly negative so I've not approached
>> anyone yet.
>
> With polkit we can help. I think just about everyone in the programming part
> of the team had done polkit at one point or another.

Thanks, I'll push my systemsettings module when it's sort of sensible
then get someone to help PolKit it, or at least explain to me what I
need to do.

>
> As for the comments: you should beware of how important they are. They neither
> reflect common opinion nor particularly technical reasoning (especially the
> ones on your post from a quick glance). The only two valuable concerns I
> noticed were: supreme PAM support and enterprise readiness. Both things that
> should entirely be secured before going anywhere with LightDM IMHO.
>
>> Moving forwards, I think I should take discussion about KDE and
>> LightDM off the kubuntu ML and maybe onto the LightDM ML? I'm not sure
>> if I'm bugging people. I also need some opinions from you and to get
>> some more people on board.
>
> If you feel it makes more sense there... Having stuff here is not particularly
> distrubing though, especially since we get free status updates that way :P
>
> What sort of people do you need?
>
I know from the past that one-man projects tend to fail eventually, if
I get busy or die in a catastrophic accident there needs to be people
who can continue the work. Mostly I just need people to follow the
development to tell me if I'm doing something stupid.

Also accessibility is on our goal list (as of now) I know nothing
about that. What stuff is important in a login manager?
- Choosing large fonts?
- Screen readers?

Does this need to happen at run time, or can it be in the systemsettings module?

> regards,
> Harald
>
>

--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 

Thread Tools




All times are GMT. The time now is 04:49 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org