Re: New module proposal: LightDM
Ray/Robert: On 10/22/10 12:17 AM, Ray Strode wrote: (speaking as one of the 3 maintainers of GDM) Speaking as another... On Thu, Oct 21, 2010 at 12:02 AM, Robert Ancellrobert.anc...@gmail.com wrote: - The GDM greeter is slow due to it loading the GNOME session, the example GTK+ LightDM greeter is very lightweight (so is comparable to the speed of the old GDM and newer display managers like LXDM). Using GNOME session / g-s-d /etc is one of GDMs main features. The point is for there to be consistent experience on the login screen and in the session. If GDM is too slow because of GNOME session then GNOME session needs to be fixed, otherwise login after GDM will be too slow too. Anyway, if gnome-session is slow on your machine we should start by profiling it and figuring out why. I agree that GDM's deep integration with GNOME is one of its great features. GDM is clearly the login manager of choice if you want a very consistent experience between the login manager and the GNOME desktop. However, not everyone really needs or wants the degree of integration that GDM provides with GNOME. It should, I think, be possible to define a lighter degree of GNOME integration for a display manager that intends to be a bit more desktop neutral/agnostic than GDM, but still be a part of the GNOME Desktop. Think about Ephipany. Users who really want tight GNOME integration may prefer Epiphany, but some users may prefer other web browsers for various reasons. - All X server users have pretty much the same requirements beyond the login GUI. By using LightDM the development effort of maintaining the display manager can be shared between projects (GNOME, KDE, LXDE, XFCE). So you're not proposing LightDM to become part of GNOME, you're just proposing GDM get dropped and LightDM become an external dependency? I thought the new release model was all about choice and flexibility. I would think there should be room enough for choices. Have you talked to the other projects about this? We had some discussions some time back with Oswald (KDE developer) about standardizing on one display manager a few years ago: http://mail.gnome.org/archives/gdm-list/2007-October/msg00013.html (added him to cc list) Wasn't that the same discussion where Oswald said that he would only accept a standardized display manager if it didn't regress any current KDM features and if we did all the work? I believe Jon responded by agreeing that he was willing to do it. See here: http://mail.gnome.org/archives/gdm-list/2007-October/msg00014.html Unfortunately, though, I do not think we have progressed much towards these ends since then. Anyway, I'm obviously in favor of keeping GDM in GNOME. So am I, but I'd think there should be room for more than one display manager choice in GNOME. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: LightDM
Thanks for the feedback Ray, I hadn't considered if GNOME recommend more than one display manager? I don't know. I'm trying to align LightDM as a freedesktop.org project closely related to the X server (and thus an external dependency) with a GNOME greeter developed as a full GNOME project. For some background, LightDM came from a weekend project after trying to document the greeter-daemon interface and I was trying to better understand the interactions in GDM. While I appreciate the use of a full session for the greeter has it's advantages, I'm not sure they're all necessary for the limited GUI required in a greeter. It really comes down to flexibility - I think any capable application developer should be able to develop a greeter (with a full session if required) without needing detailed knowledge of how the display manager works. I had been trying to get this interface into GDM, but I'd come to the conclusion that the architecture of GDM is overly complex and that holds back innovation. The weekend project confirmed to me that we can have all the same features without the complexity. I am talking with other projects and trying to get people working together. I'd like to see the fragmentation in display managers reduce so we can look at the daemon as the boring reliable bit and have people go wild designing new interfaces! On 22 October 2010 16:17, Ray Strode halfl...@gmail.com wrote: Hi, (speaking as one of the 3 maintainers of GDM) On Thu, Oct 21, 2010 at 12:02 AM, Robert Ancell robert.anc...@gmail.com wrote: - The GDM greeter is slow due to it loading the GNOME session, the example GTK+ LightDM greeter is very lightweight (so is comparable to the speed of the old GDM and newer display managers like LXDM). Using GNOME session / g-s-d /etc is one of GDMs main features. The point is for there to be consistent experience on the login screen and in the session. If GDM is too slow because of GNOME session then GNOME session needs to be fixed, otherwise login after GDM will be too slow too. Anyway, if gnome-session is slow on your machine we should start by profiling it and figuring out why. - The GDM greeter has very limited themeing capabilities. A contributor to LightDM (PCMan) was able to quickly write a new greeter that used GtkBuilder and provided comparable themeing support to the old GDM. GDM uses the standard theming mechanism as the rest of GNOME. This a good thing. Making GDM use GNOME components and integrate with GNOME is not a bad thing. It used to not do that and was explicitly changed... Of course, things will need to be rethought about in a post- GNOME 3 world (use mutter / clutter?) - While it is technically possible to write an alternate greeter for GDM, in practise it is too difficult. LightDM has been designed from the start to make writing a greeter no harder than a standard X application. Granted, the interface between greeter and daemon isn't as clean as it could be. Still, 1) it's obviously not too difficult, or there couldn't be one functioning greeter 2) When writing a new greeter becomes a priority to someone, the interface is completely changeable. It's a private interface so it can be changed in any way that's needed. - All X server users have pretty much the same requirements beyond the login GUI. By using LightDM the development effort of maintaining the display manager can be shared between projects (GNOME, KDE, LXDE, XFCE). So you're not proposing LightDM to become part of GNOME, you're just proposing GDM get dropped and LightDM become an external dependency? Have you talked to the other projects about this? We had some discussions some time back with Oswald (KDE developer) about standardizing on one display manager a few years ago: http://mail.gnome.org/archives/gdm-list/2007-October/msg00013.html (added him to cc list) Anyway, I'm obviously in favor of keeping GDM in GNOME. I admit it has some baggage (some of it removed and added back later by popular demand), but overall GDM is in really good shape as a project.. FWIW, your various patches over the years have been a part of getting GDM to where it is. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: LightDM
Le vendredi 22 octobre 2010 à 01:17 -0400, Ray Strode a écrit : Using GNOME session / g-s-d /etc is one of GDMs main features. The point is for there to be consistent experience on the login screen and in the session. That, I fully agree with. This is a major feature of GDM, that makes extending it easy and makes a11y support a breeze. It’s really a shame that LightDM doesn’t re-use this concept. Anyway, I'm obviously in favor of keeping GDM in GNOME. I admit it has some baggage (some of it removed and added back later by popular demand), but overall GDM is in really good shape as a project.. FWIW, your various patches over the years have been a part of getting GDM to where it is. I wouldn’t really call it in “good shape” from a distributor’s point of view. We have to include an ever-growing number of complex patches just to have the features that we consider essential, and development upstream is happening faster than the pace at which we can get these patches merged. This situation is not new and we also carry too many patches in the 2.20 branch, but it’s not getting better; the sole 2.30.2 → 2.30.3 upgrade included larger changes than all our patches added. Having had to deal again with GDM’s labyrinth of classes, I came to the conclusion that Robert’s decision to restart a project from scratch was the right one. This means we don’t have the same priorities for GDM development, and of course it’s fine; you’re doing whatever you want with your own project. But LightDM seems to focus much more on features that do matter for us. Cheers, -- .''`. : :' : “You would need to ask a lawyer if you don't know `. `' that a handshake of course makes a valid contract.” `--- J???rg Schilling ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: (not) proposing Snowy for GNOME 3.0
On Thu, 2010-10-21 at 21:35 -0700, Sandy Armstrong wrote: == GNOME Web Platform == There is no GNOME web platform. There are no new libraries being proposed for use by all GNOME web modules. It feels way too early to try to make those sorts of decisions. We need another module or two before we discover what can and should be shared. I will say that even if we end up with an Online Desktopish goal, we should not strive for one big monster web app.I think it makes sense to focus on smaller, single-purpose web apps with sensible integration points. For example, we could have a Mugshot-like identity app for Teh Social, and have it aggregate info from apps like Snowy. We could tie apps together with existing standards like OpenID and OAuth. We could come up with conventions for building RESTful APIs, standardize on JSON, etc etc. We could build standard GTK+ widgets for authenticating with GNOME web services. Whatever makes sense to make integration between the GNOME desktop and the GNOME web easy on developers and users. yes, maybe it would make sense to have a generic sync API, so that the same API and server could be used for syncing notes, contacts, calendar events, etc. I don't think that would make a monster app, if it's just a syncing server implementing a single API, wouldn't it? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: (not) proposing Snowy for GNOME 3.0
On Fri, Oct 22, 2010 at 3:27 AM, Rodrigo Moya rodr...@gnome-db.org wrote: On Thu, 2010-10-21 at 21:35 -0700, Sandy Armstrong wrote: == GNOME Web Platform == There is no GNOME web platform. There are no new libraries being proposed for use by all GNOME web modules. It feels way too early to try to make those sorts of decisions. We need another module or two before we discover what can and should be shared. I will say that even if we end up with an Online Desktopish goal, we should not strive for one big monster web app. I think it makes sense to focus on smaller, single-purpose web apps with sensible integration points. For example, we could have a Mugshot-like identity app for Teh Social, and have it aggregate info from apps like Snowy. We could tie apps together with existing standards like OpenID and OAuth. We could come up with conventions for building RESTful APIs, standardize on JSON, etc etc. We could build standard GTK+ widgets for authenticating with GNOME web services. Whatever makes sense to make integration between the GNOME desktop and the GNOME web easy on developers and users. yes, maybe it would make sense to have a generic sync API, so that the same API and server could be used for syncing notes, contacts, calendar events, etc. I don't think that would make a monster app, if it's just a syncing server implementing a single API, wouldn't it? I disagree. Not every app has the same sync needs. I think most apps could get away with a simpler sync than what Tomboy currently uses. And even if we had a generic sync API, we'd end up being forced to either store giant JSON strings in the database, or be forced to use an unstructured DB like Couch, or have the model for each data type defined in one app. All of these have potential downsides. But my experience is limited to sync for one app, so I could certainly be wrong here. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: (not) proposing Snowy for GNOME 3.0
On Fri, 2010-10-22 at 12:27 +0200, Rodrigo Moya wrote: On Thu, 2010-10-21 at 21:35 -0700, Sandy Armstrong wrote: == GNOME Web Platform == There is no GNOME web platform. There are no new libraries being proposed for use by all GNOME web modules. It feels way too early to try to make those sorts of decisions. We need another module or two before we discover what can and should be shared. I will say that even if we end up with an Online Desktopish goal, we should not strive for one big monster web app.I think it makes sense to focus on smaller, single-purpose web apps with sensible integration points. For example, we could have a Mugshot-like identity app for Teh Social, and have it aggregate info from apps like Snowy. We could tie apps together with existing standards like OpenID and OAuth. We could come up with conventions for building RESTful APIs, standardize on JSON, etc etc. We could build standard GTK+ widgets for authenticating with GNOME web services. Whatever makes sense to make integration between the GNOME desktop and the GNOME web easy on developers and users. yes, maybe it would make sense to have a generic sync API, so that the same API and server could be used for syncing notes, contacts, calendar events, etc. I don't think that would make a monster app, if it's just a syncing server implementing a single API, wouldn't it? I'm not sure but there was some time ago part of implementation in CouchDB (there is evolution-couchdb etc.). At least the replication could be done by standard tool (like couchdb) and the web GUI will contact with the same standard backend. It may or may not be couchdb but couchdb implementations on client side already exists. So basicly it would be reimplementation of Ubuntu One on some license (AGPL?). Regatds signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: external dependency review for 2.91
On Mon, 2010-10-04 at 11:11 +0100, Bastien Nocera wrote: On Thu, 2010-09-30 at 22:44 -0400, Matthias Clasen wrote: Hi, I looked over the external dependencies for 2.91 [1]. I've bumped the recommended versions to current versions in many places. There are some places where we need to bump mnimal versions: We'll probably also need to add libsocialweb. nautilus-sendto for GNOME3 will depend on it, as well as the Web Accounts panel for the control-center. I've done a tarball release and added libsocialweb to jhbuild to that effect. I've also cleaned up the dependencies on nautilus-sendto. Bear in mind that some bits still aren't implemented, and the build system is very ad hoc (eg. works for me). I'll make some of the dependencies optional when at least a few plugins have been cleaned up. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: external dependency review for 2.91
Bastien Nocera wrote: On Mon, 2010-10-04 at 11:11 +0100, Bastien Nocera wrote: On Thu, 2010-09-30 at 22:44 -0400, Matthias Clasen wrote: Hi, I looked over the external dependencies for 2.91 [1]. I've bumped the recommended versions to current versions in many places. There are some places where we need to bump mnimal versions: We'll probably also need to add libsocialweb. nautilus-sendto for GNOME3 will depend on it, as well as the Web Accounts panel for the control-center. I've done a tarball release and added libsocialweb to jhbuild to that effect. I've also cleaned up the dependencies on nautilus-sendto. It depends on librest, is it also proposed? It depends on gconf and dbus-glib, are there plans to migrate to gsettings and gdbus? And more fundamentally, as we are reorganizing our modulesets, what was the motivation to add this as an external dependency, instead of proposing it as a GNOME module? Frederic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: external dependency review for 2.91
{sorry I didn't notice this before my previous message}
Bastien Nocera wrote:
We'll probably also need to add libsocialweb. nautilus-sendto for GNOME3
will depend on it, as well as the Web Accounts panel for the
control-center.
I've done a tarball release and added libsocialweb to jhbuild to that
effect. I've also cleaned up the dependencies on nautilus-sendto.
libsocialweb includes official logos for some services (Twitter,
Last.fm, and Vimeo), do you know if this is legally ok?
Frederic
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: external dependency review for 2.91
On Fri, 2010-10-22 at 15:08 +0200, Frederic Peters wrote:
{sorry I didn't notice this before my previous message}
Bastien Nocera wrote:
We'll probably also need to add libsocialweb. nautilus-sendto for GNOME3
will depend on it, as well as the Web Accounts panel for the
control-center.
I've done a tarball release and added libsocialweb to jhbuild to that
effect. I've also cleaned up the dependencies on nautilus-sendto.
libsocialweb includes official logos for some services (Twitter,
Last.fm, and Vimeo), do you know if this is legally ok?
Yep. And they're not included in the theme paths because Intel's
agreements on using those logos didn't apparently the ability to theme
them (or the ability not to).
I'm sure that Rob would have more info about that.
I opened a bug about a similar problem:
http://bugs.meego.com/show_bug.cgi?id=5944
Cheers
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: external dependency review for 2.91
On Fri, 2010-10-22 at 14:53 +0200, Frederic Peters wrote: Bastien Nocera wrote: On Mon, 2010-10-04 at 11:11 +0100, Bastien Nocera wrote: On Thu, 2010-09-30 at 22:44 -0400, Matthias Clasen wrote: Hi, I looked over the external dependencies for 2.91 [1]. I've bumped the recommended versions to current versions in many places. There are some places where we need to bump mnimal versions: We'll probably also need to add libsocialweb. nautilus-sendto for GNOME3 will depend on it, as well as the Web Accounts panel for the control-center. I've done a tarball release and added libsocialweb to jhbuild to that effect. I've also cleaned up the dependencies on nautilus-sendto. It depends on librest, is it also proposed? I would guess so. I thought it was already in the list of deps, as it was already defined in jhbuild. It depends on gconf and dbus-glib, are there plans to migrate to gsettings and gdbus? GSettings, probably, dbus-glib, I have no idea. I personally don't see removing dbus-glib usage as something urgent, especially when a large portion of the code is just dbus interaction (like in libsocialweb, or in gnome-bluetooth's libraries). And more fundamentally, as we are reorganizing our modulesets, what was the motivation to add this as an external dependency, instead of proposing it as a GNOME module? I stopped reading the module reorganisation mails when it got into an l10n discussion, and I already made my concerns about it known. At the end of the day, I'm not the libsocialweb maintainer, and I needed to add it to get the nautilus-sendto in master to build. Feel free to move the definition around. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: LightDM
Hi, On Fri, Oct 22, 2010 at 5:31 AM, Josselin Mouette j...@debian.org wrote: Le vendredi 22 octobre 2010 à 01:17 -0400, Ray Strode a écrit : Using GNOME session / g-s-d /etc is one of GDMs main features. The point is for there to be consistent experience on the login screen and in the session. That, I fully agree with. This is a major feature of GDM, that makes extending it easy and makes a11y support a breeze. It’s really a shame that LightDM doesn’t re-use this concept. Right, GDM used to work the way LightDM apparently works now, and it was changed because this way is better. Anyway, I'm obviously in favor of keeping GDM in GNOME. I admit it has some baggage (some of it removed and added back later by popular demand), but overall GDM is in really good shape as a project.. FWIW, your various patches over the years have been a part of getting GDM to where it is. I wouldn’t really call it in “good shape” from a distributor’s point of view. We have to include an ever-growing number of complex patches just to have the features that we consider essential, and development upstream is happening faster than the pace at which we can get these patches merged. I understand this point--maintaining a load of patches can be totally unfun. We discussed this before on gdm-list and I think we've made progress on that front since then. If you drop by #gdm and ping me, we can figure out what to do about your remaining patches. This situation is not new and we also carry too many patches in the 2.20 branch, but it’s not getting better; the sole 2.30.2 → 2.30.3 upgrade included larger changes than all our patches added. Sure, but those changes were important bug fixes and performance enhancements. I realize even if the changes were worthwhile it doesn't make maintenance for you any easier if you've complex patches to rebase, though. Having had to deal again with GDM’s labyrinth of classes, I came to the conclusion that Robert’s decision to restart a project from scratch was the right one. GDM does have a lot of code, but I'm happy to explain any parts of the code that seem confusing. I will say there are some classes in there that aren't compiled in. We could probably cull some of the excess fat to make it easier to see the active code and just add it back from history when if they become important again. One example of something that's #if 0'd out factory mode. This is where GDM always runs in the background on a VT and the user is sent to that VT when ever they need a login screen. This helps fast user switching cases, and potentially paves the way for trusted path password dialogs (which I think Robert was alluding to as a potential future feature for LightDM). That's something we could potentially drop for now. This means we don’t have the same priorities for GDM development, and of course it’s fine; you’re doing whatever you want with your own project. I don't see GDM as my project. I see my work on GDM as way of helping GNOME. I do see GNOME as my project (well our project) though. Again, I think one of the most important features of the display manager is integration. We have to stop thinking about GNOME as this thing layered on top of the OS, and start thinking of it *as the OS*. We need to be able to rely on important components being available and we need to leverage their presence to provide a slick, coherent experience to the user. As an example, the user switch applet is being moved to gnome-panel (and a comparable version already exists in the shell). Another example is the accounts-dialog (which is slated to go into control-center pretty soon I think. see the thread i posted about accounts daemon a few days ago) is used to configure things like Automatic Login. This is all under the umbrella of providing a consistent, unified experience to the user. The core of gnome shouldn't be hot swappable--it defines what gnome is. I'd say the login experience is central to the core user experience. But LightDM seems to focus much more on features that do matter for us. Which features are those? I think there may still be some lingering unhappiness about GDM losing features (like the themeable greeter) when it was reinvented in 2.22. Some of the criticism then was fair criticism and we worked hard to add back the important things in a way that makes the most sense. We didn't add back the themeable greeter for good reasons. It had bizarre rendering bugs, an underspecified file format, and also wasn't accessible. GDM had to ship with a separate,plain greeter that wasn't enabled by default in most distros for users who wanted an accessible login. That's not very courteous and it doesn't fit in with our ideals of universal access. Now we have a greeter that's accessible, uses the core features of the desktop, uses the same theming system as the rest of GNOME, supports the same animated wallpapers, etc, as the rest of GNOME. It''s everything the themable greeter
Re: New module proposal: LightDM
Hi, On Fri, Oct 22, 2010 at 2:11 AM, Brian Cameron brian.came...@oracle.com wrote: I agree that GDM's deep integration with GNOME is one of its great features. GDM is clearly the login manager of choice if you want a very consistent experience between the login manager and the GNOME desktop. However, not everyone really needs or wants the degree of integration that GDM provides with GNOME. I feel like GNOME should be catering to GNOME's users, and we're doing a disservice to them if we don't provide integration. It should, I think, be possible to define a lighter degree of GNOME integration for a display manager that intends to be a bit more desktop neutral/agnostic than GDM, but still be a part of the GNOME Desktop. I disagree. I think that's going the wrong direction. Think about Ephipany. Users who really want tight GNOME integration may prefer Epiphany, but some users may prefer other web browsers for various reasons. I don't think that's a fair card to play. Firefox has a lot more marketshare than GNOME, has a ton of development resources, etc, so distros embrace it to provide brand recognition, get security updates, etc. Also, back when this was a hot button issue, you needed firefox installed to run epiphany. Firefox also goes to great lengths to try to integrate as well as it can with GNOME. Anyway, I kind of wish distros embraced ephipany more. The mozilla foundation is doing a lot for the open source community (really, a ton, more than anyone else problably), the health of the internet, etc, but their goals don't always perfectly align with GNOME's or distros. Also, they have a powerful trademark they need to protect, which complicates things in various ways I don't want to get into here. I thought the new release model was all about choice and flexibility. Nope, I think you misunderstood (or I did). The new release model is about putting even apps on an even footing. It doesn't apply to the core of the OS. Users should be able to pick which apps they want, not which window manager, settings daemon, or login window they want. From a desktop point of view, these things are central to defining what the GNOME is. They are the OS which defines the stuff around the apps. Our mantra should be integration, coherency, consistency, just works for the OS. Adam Jackson did an awesome email a while back called Linux is not about choice that's mildly relevant, so I'll post it: https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00861.html We really need to band together and focus on making our OS better, not more flexible, just better. I don't want to ship a bucket of parts to our users and leave them to fend for themselves. I want the user to get something refined, cohesive, and out-of-their way so it fades into the background while they're trying to get their job done (whatever job that may be). They shouldn't have think about the computer when they use the computer as a tool to do something else. We're not there yet. It should be an important goal. The only way we'll get there is if we work less on modularizing and more on integrating. I would think there should be room enough for choices. Have you talked to the other projects about this? We had some discussions some time back with Oswald (KDE developer) about standardizing on one display manager a few years ago: http://mail.gnome.org/archives/gdm-list/2007-October/msg00013.html (added him to cc list) Wasn't that the same discussion where Oswald said that he would only accept a standardized display manager if it didn't regress any current KDM features and if we did all the work? Right, that's why I was wondering if Robert had talked to him yet, when he mentioned he wants LightDM to be cross-desktop. Anyway, I'm obviously in favor of keeping GDM in GNOME. So am I, but I'd think there should be room for more than one display manager choice in GNOME. Again, I disagree here for the reasons mentioned above. We need to focus, not splinter. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: LightDM
Hi, On Fri, Oct 22, 2010 at 2:50 AM, Robert Ancell robert.anc...@gmail.com wrote: While I appreciate the use of a full session for the greeter has it's advantages, I'm not sure they're all necessary for the limited GUI required in a greeter. It's not necessary (i mean there's a lot of prior art showing that). I'd argue though that doing it any other way is wrong. It really comes down to flexibility - I think any capable application developer should be able to develop a greeter (with a full session if required) without needing detailed knowledge of how the display manager works. I agree the interface between the greeter and daemon in GDM could be cleaned up, and doing that would be a worthwhile thing to do. I had been trying to get this interface into GDM, but I'd come to the conclusion that the architecture of GDM is overly complex and that holds back innovation. We have the ability to simplify the complicated parts of the architecture where necessary. It's just internal code and it can be changed to fit needs as necessary. There's no API/ABI worries or anything like that. We can fix problems, all it takes is fixing them... and of course there's 3 maintainers of GDM that are very familiar with the code. We're all frequently available to answer questions, too (although, like everyone else we're all busy doing other things as well) I am talking with other projects and trying to get people working together. I'd like to see the fragmentation in display managers reduce so we can look at the daemon as the boring reliable bit and have people go wild designing new interfaces! Ensuring the display manager is flexible enough to meet the expectations of designers is an important goal. There's no doubt, telling a designer with a competent design, we can't implement that often means the user loses. I think that's why one of the main reasons parts of GNOME 3 are getting themed with CSS and getting written in javascript. Adding another display manager fragments things even more, though. 2 display managers for GNOME would be bad for GNOME. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: LightDM
Ray: On 10/22/10 09:50 AM, Ray Strode wrote: However, not everyone really needs or wants the degree of integration that GDM provides with GNOME. I feel like GNOME should be catering to GNOME's users, and we're doing a disservice to them if we don't provide integration. Agreed, and I agree that GDM should focus on providing this integration. Overall, it does a great job at that. It should, I think, be possible to define a lighter degree of GNOME integration for a display manager that intends to be a bit more desktop neutral/agnostic than GDM, but still be a part of the GNOME Desktop. I disagree. I think that's going the wrong direction. I fully agree with you that having a tightly integrated display manager like GDM makes a lot of sense. I would go so far as to say it makes a lot of sense for the most common use-cases (e.g. single-user desktop/laptop environments probably being the most common). However, to suggest that GDM is the best solution to all problems and use-cases is probably overselling. Some examples: - non OpenGL GNOME is moving towards OpenGL with GNOME 3.0. The GNOME community recommends using gnome-session/gnome-panel for the classic look. I imagine GDM will eventually go the clutter/OpenGL route. Does GDM plan to always support non-OpenGL environments, or is there value in having a lighter display manager to focus on this sort of use case? - non-Linux GDM and ConsoleKit are very Linux-focused and include a fair amount of code that is hard to get working on non-Linux distributions. It may not be reasonable for GDM to position itself as the best display manager for all operating systems. - Multiple Desktop Environments In environments where a distro allows the user to configure what desktop to use on the system, GDM may not make sense since it requires so much of the GNOME stack to be installed. If the user decides to not install GNOME, then using a display manager that does not require so much of the GNOME stack to be installed is a plus. Perhaps the GNOME community doesn't really care so much about this use case since we might not care what non-GNOME users use. But, I am just highlighting that some distros may choose to not use GDM (or not use it all the time) just because they might want a display manager that is not quite so integrated with one particular desktop. - Security/Paranoia In general, the more code that runs at login time creates more opportunity for malicious users find ways to compromise the code. I think that the GDM team has done a great job locking things down so that it is reasonably secure. However, it is impractical to audit everything GDM now depends upon (metacity, gnome-session, gnome- settings-daemon, GConf, etc.) so it is hard to know for sure. The fact that this infrastructure is constantly churning (e.g. metacity to mutter, GNOME 2 to GNOME Shell) means that new issues could pop-up anytime on upgrade. This degree of paranoia is probably not important to most GNOME users who just want a login screen to keep random people from logging into their laptop. However, there are environments where security is more of a concern and where users would want to trade some usability for more security. It is easier for a lighter display manager to be audited and to provide more reasonable assurance that the code is stable and secure simply because considerably less code is running at login time. Just a few examples of use-cases that may not be in-line with the direction of the GDM project. Think about Ephipany. Users who really want tight GNOME integration may prefer Epiphany, but some users may prefer other web browsers for various reasons. I don't think that's a fair card to play. I was not playing any card. I was just trying to provide an example of another situation where GNOME supports multiple programs with differing degrees of GNOME integration. I thought the new release model was all about choice and flexibility. Nope, I think you misunderstood (or I did). The new release model is about putting even apps on an even footing. It doesn't apply to the core of the OS. While I agree that the display manager is more core than the average application, I do think there are plenty of reasons that could cause a user or distro to decide what display manager makes sense in different environments. Users should be able to pick which apps they want, not which window manager, settings daemon, or login window they want. From a desktop point of view, these things are central to defining what the GNOME is. They are the OS which defines the stuff around the apps. Our mantra should be integration, coherency, consistency, just works for the OS. Adam Jackson did an awesome email a while back called Linux is not about choice that's mildly relevant, so I'll post it: https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00861.html Not everybody who uses
Call for a new Conglomerate maintainer!
Hi all, in my opinion, Conglomerate is the best XML editor ever. but the last release was five years ago. In the meantime, Conglomerate was able to keep its users alive, but the application itself seems to rest in peace...A lot of new or completed translations have arrived. The user manual can now be handled by the gnome-doc-utils, and we have some bugfixes, too. Last year I wrote to the maintainer Geert Stappers to find out more about what he thinks about a release. He answered that he doesn't see any problems, unless the changes in Git are only translations and bugfixes which doesn't affect the libraries. But he hasn't really much time left to pick up the development again. In fact, we need a new maintainer to wake up the development. Who would be able and willing to take this task over? Otherwise, a lot of work of our translators would be done just for the trash. Cheers, Mario FreeLotto - das kostenlose Lotto von freenet! Jeden Tag die Chance auf 2 Millionen Euro nutzen. Jetzt gratis Lotto spielen auf http://freelotto.freenet.de! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: LightDM
I also want to say something slightly off-topic regarding impulse to change. A lot of users hate when things they use get changed. It screws up their workflows, etc, and so many changes are controversial. Often there's a gut reaction can you provide a way for me get things back to the old way from the new way. I'm sure a lot of people on this list know what I'm talking about. For some reason, that same impulse doesn't seem as strong when users change to different functionally similar apps. What I mean is, it's not okay if App A changes the way something works or removes a feature, but if App B never provided that feature in the first place then the user may switch from App A to App B and be quite happy (even though App B completely changes their workflows!) I've never understood this, but I've seen it happen a lot (not talking about LightDM and GDM in particular here, just an off topic side note) My guess on this is if App B significantly improves their experience then users don't worry too much about features that have gone. App A+1 is like an App B but without the step change in improvement and so users are more critical of removals. Perhaps the only solution as a module maintainer is to only allow removals with major improvements (almost impossible if you do a major refactoring). I certainly hit this problem in gcalctool... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
