Re: GNOME Feature Proposal: Backup
Dave Neary wrote: > Leaving aside "because that's the way it is" as a reason for a second, > what are the potential issues we'd have using Launchpad? > > * Bug reporters would have to have an easy way to report bugs against > Deja Dup through gnome.org > * GNOME developers would need to reassign bugs to deja dup which were > incorrectly assigned to another GNOME module > * Deja Dup developers would presumably want to do the same thing in the > other direction > > Are there others I'm missing? * A way to subscribe/CC GNOME contributors to Deja Dup bugs * Need to be able to target bugs at specific GNOME releases * The release team needs to be able to mark and track release critical bugs (important ones, blockers, etc). I gather that this is currently done by querying Bugzilla. The latter two are essential, I guess. We also have the fragmentation issue to think about: if Deja Dup uses LP, what's to say other modules can't use it too? Or Source Forge? Or Google Code? Or Trac installations... Allan -- Blog: http://afaikblog.wordpress.com/ IRC: aday on irc.gnome.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
3.2 features: login screen
Over the past week, I've been working with Ray on fleshing out the plans for gdm in 3.2. We are aiming for 2 things for 3.2: - A new 'shell-style' greeter. You can see a mockup on the feature page. - An 'initial-setup' tool. The goal here is to allow setting up a few essential things on a new system before you start to use it for the first time. More details can be found in https://live.gnome.org/ThreePointOne/Features/LoginScreen. Please go and read them before replying. Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
3.2 features: color management
Over the past week, Richard and I have spent a lot of time in #gnome-design, discussing the goals and design for a 'color' control-center panel. This was hard; color management is a very technical topic. But what we have come up with looks good enough and is limited enough in scope that we are comfortable proposing it as a 3.2 feature. You can read the details here: https://live.gnome.org/ThreePointOne/Features/ColorManagement Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.2 features: login screen
On Fri, 2011-05-20 at 08:02 -0400, Matthias Clasen wrote: > Over the past week, I've been working with Ray on fleshing out the > plans for gdm in 3.2. We are aiming for 2 things for 3.2: > > - A new 'shell-style' greeter. You can see a mockup on the feature page. Will the UI be something that can end up being shared with gnome-screensaver, to avoid mismatching UIs? > - An 'initial-setup' tool. The goal here is to allow setting up a few > essential things on a new system before you start to use it for the > first time. Given that, at least for a transition period, it might replicate some of the settings done during the installation, would it be possible to disable particular pages from being shown, so as to have no overlap. I'd expect distributors to make changes to the .desktop file to disable particular pages until their installer catches up. > More details can be found in > https://live.gnome.org/ThreePointOne/Features/LoginScreen. Please go > and read them before replying. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.2 features: color management
On 20 May 2011 13:24, Matthias Clasen wrote: > Over the past week, Richard and I have spent a lot of time in > #gnome-design, discussing the goals and design for a 'color' > control-center panel. This was hard; color management is a very > technical topic. I just wanted to thank all the people in #gnome-design for their patience and support - color is indeed hard for mere mortals to understand. When I've pushed some of the initial code into gnome-control-center and gnome-settings-daemon I'll post some screenshots of what it looks like. Richard. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.2 features: login screen
Le vendredi 20 mai 2011 à 08:02 -0400, Matthias Clasen a écrit : > - An 'initial-setup' tool. The goal here is to allow setting up a few > essential things on a new system before you start to use it for the > first time. Please don’t do this. It would merely duplicate the functionality already in the installer. A system should be immediately usable once the installation is finished. Having to run things after it has booted would be a jump 5 years backwards. -- .''`. Josselin Mouette : :' : `. `' `- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.2 features: login screen
On Fri, May 20, 2011 at 8:39 AM, Josselin Mouette wrote: > > Please don’t do this. It would merely duplicate the functionality > already in the installer. > > A system should be immediately usable once the installation is finished. There's plenty of scenarios where this logic doesn't work: - preinstalled or otherwise provisioned systems - generally any situation where the person doing the installation is not the same as the person using the system And existing practice seems to disagree with your vision, if you look at things like firstboot or yast. Anyway, if your installer gets it all perfect, you can just not use this feature, it is entirely optional. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.2 features: login screen
Le vendredi 20 mai 2011 à 09:07 -0400, Matthias Clasen a écrit : > > A system should be immediately usable once the installation is finished. > > There's plenty of scenarios where this logic doesn't work: > - preinstalled or otherwise provisioned systems > - generally any situation where the person doing the installation is > not the same as the person using the system This is precisely the kind of situations where the installer needs to take care of everything. > And existing practice seems to disagree with your vision, if you look > at things like firstboot or yast. We used to have that too. It’s a hindrance, and it needlessly splits the installation process in two. It feels to me like you want to replace firstboot by a graphical thingy and put a GNOME label on a Red Hat-specific program. -- .''`. Josselin Mouette : :' : `. `' `- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.2 features: login screen
Il giorno ven, 20/05/2011 alle 08.02 -0400, Matthias Clasen ha scritto: > - An 'initial-setup' tool. The goal here is to allow setting up a few > essential things on a new system before you start to use it for the > first time. I strongly suggest to postpone this, if planned to be performed after installation and before first login to setup the "master" user (as it seems reading the wiki, see "create an account panel"). We still have to choose what GNOME OS will be and we are yet planning to overlap distro role :) But if you want to show a similar assistant to each user _after_ his/her first successful login, it could be fine and interesting (but I suppose should be moved from gdm to a separate project). If so, do you plan to add hooks for third parties (for instance, an hook to allow gwibber to include its own panel)? Cheers, Luca ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.2 features: login screen
Le vendredi 20 mai 2011 à 15:12 +0200, Josselin Mouette a écrit : > Le vendredi 20 mai 2011 à 09:07 -0400, Matthias Clasen a écrit : > > > A system should be immediately usable once the installation is finished. > > > > There's plenty of scenarios where this logic doesn't work: > > - preinstalled or otherwise provisioned systems > > - generally any situation where the person doing the installation is > > not the same as the person using the system > > This is precisely the kind of situations where the installer needs to > take care of everything. But should (and can) the installer also take care of setting up your Google/Facebook/Yahoo.. account? Saving your WPA passphrase in your user keyring? That will probably be even harder to do than from a special GDM session. Or maybe the installer could just take care of creating the user, and the initial setup would only be something to run for each new user? Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.2 features: login screen
On Fri, 2011-05-20 at 15:19 +0200, Luca Ferretti wrote: > Il giorno ven, 20/05/2011 alle 08.02 -0400, Matthias Clasen ha scritto: > > > - An 'initial-setup' tool. The goal here is to allow setting up a few > > essential things on a new system before you start to use it for the > > first time. > > I strongly suggest to postpone this, if planned to be performed after > installation and before first login to setup the "master" user (as it > seems reading the wiki, see "create an account panel"). > > We still have to choose what GNOME OS will be and we are yet planning to > overlap distro role :) Distros shouldn't have been doing that in the first place, and it's optional. > But if you want to show a similar assistant to each user _after_ his/her > first successful login, And how do you create the new users? Either you have something provided by the distro, or you'll need to log in as root. Neither of which will integrate nicely in GNOME. > it could be fine and interesting (but I suppose > should be moved from gdm to a separate project). > If so, do you plan to add hooks for third parties (for instance, an hook > to allow gwibber to include its own panel)? Huh, what? We're talking about system configuration. What language do you use, what keyboard setup do you want, then you can login and do your stuff. And I don't see why we'd be allowing Gwibber to add its own panel any more in the first time assistant than in gnome-control-center. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.2 features: color management
Il giorno ven, 20/05/2011 alle 08.24 -0400, Matthias Clasen ha scritto: > You can read the details here: > https://live.gnome.org/ThreePointOne/Features/ColorManagement "In GNOME 3.2, colord is an approved external dependancy and many GNOME applications should use this to make a 100% color managed desktop." Ehmm.. "is"? really? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.2 features: color management
On 20 May 2011 14:31, Luca Ferretti wrote: > "In GNOME 3.2, colord is an approved external dependancy and many GNOME > applications should use this to make a 100% color managed desktop." > > Ehmm.. "is"? really? I sent an email to DDL prior to the release of 3.0 that colord would be a dep for gnome-color-manager in GNOME 3.2. Nobody at all complained. I've repeatedly asked people to package it, and since LGM it's been appearing in other distros slowly. It's not on ThreePointTwoExternalDependencies wiki page as I can't see that one exists yet. The quieten everybody down, colord compiles just fine on the BSD's and on Solaris, although without xrandr, udev and sane integration, it doesn't really do anything interesting at all. :-) Richard. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.2 features: login screen
Il giorno ven, 20/05/2011 alle 14.29 +0100, Bastien Nocera ha scritto: > On Fri, 2011-05-20 at 15:19 +0200, Luca Ferretti wrote: > > > > I strongly suggest to postpone this, if planned to be performed after > > installation and before first login to setup the "master" user (as it > > seems reading the wiki, see "create an account panel"). > > > > We still have to choose what GNOME OS will be and we are yet planning to > > overlap distro role :) > > Distros shouldn't have been doing that in the first place, and it's > optional. Could you please elaborate this "Distros shouldn't have been doing that in the first place"? > > But if you want to show a similar assistant to each user _after_ his/her > > first successful login, > > And how do you create the new users? (sarcastic mode: on) Well, in the past 15 year I was always able to do it on GNU/Linux. Which operating system are you using? :P (sarcastic mode off) > Either you have something provided > by the distro, or you'll need to log in as root. Neither of which will > integrate nicely in GNOME. Now serious, I repeat. We still have to define what GNOME OS will be. So I suggest to use 3.2 timeframe to clean up applications and libraries instead starting to work on "downstream" stuff. Do you? > > > it could be fine and interesting (but I suppose > > should be moved from gdm to a separate project). > > If so, do you plan to add hooks for third parties (for instance, an hook > > to allow gwibber to include its own panel)? > > Huh, what? We're talking about system configuration. What language do > you use, what keyboard setup do you want, then you can login and do your > stuff. And I don't see why we'd be allowing Gwibber to add its own panel > any more in the first time assistant than in gnome-control-center. Here is "web accounts" page in mockups on wiki page too and it seems more personal related. But, as I said, Gwibber was just an example for third parties. If you missed the point, I'm asking about planned behavior and features for this first time assistant: A. will it be only for "master" user or for all users? B. will it allow some kind of customization by vendor/distro/whatever? I suppose those are good question about a new feature like this. Cheers, Luca ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.2 features: color management
Il giorno ven, 20/05/2011 alle 14.37 +0100, Richard Hughes ha scritto: > On 20 May 2011 14:31, Luca Ferretti wrote: > > "In GNOME 3.2, colord is an approved external dependancy and many GNOME > > applications should use this to make a 100% color managed desktop." > > > > Ehmm.. "is"? really? > > I sent an email to DDL prior to the release of 3.0 that colord would > be a dep for gnome-color-manager in GNOME 3.2. Nobody at all > complained. IIRC it was a full "delay decision to 3.2", but I could be wrong. If so, sorry for the noise. Cheers, Luca ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
On the Interaction with the design team
Hi, I have a simple question (hopefully ddl is the right mail list for this): how are we supposed to interact with the design team? it seems that the best way is contacting them through irc in #gnome-design, but what about Gnome bugzilla? Does setting a keyword or something makes the design team in the CC of a bug or something so we can get UX advice from them? I understand that dealing with design of new features, hanging in IRC is best as it is faster to interact this way, but there are a bunch of bugs in Evince that need a thumbs up/thumbs down from the design team and I d like to know which is the best way of interacting so we can get these fixed/or wont fixed but with a clear statement from UX point of view why we are doing so. (and having a page, that probably exists, explaining the interaction between different teams would be also great) Greetings, José ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.2 features: login screen
On 20 May 2011 14:44, Luca Ferretti wrote: > Now serious, I repeat. We still have to define what GNOME OS will be. So > I suggest to use 3.2 timeframe to clean up applications and libraries > instead starting to work on "downstream" stuff. Do you? I thought 3.0 was all about getting our platform in order, and 3.2 was all about defining the OS properly. I don't think that was written down anywhere, but that was the vibe I was getting. Richard. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
On Thu, 19.05.11 23:51, Luca Ferretti (lferr...@gnome.org) wrote: > > In the future I expect more interfacing with GNOME however, and I'd thus > > like to see the discussion regarding acceptance as blessed > > dependency started early. > > Are you planning to "delegate" single module maintainers to implement > those interfaces? Do they agree on it? Do you have a list of involved > "core" modules (apart the ones listed below: gdm, gnome-session and > gnome-control-center)? Well, we'll see who will do the work in the end but I am pretty sure that somebody will do it. I am pretty sure that will be in big parts me. Bastien worked on the hostname panel. I will work on gdm, and work with the maintainers to make this happen. gnome-session is not a pressing issue right now, but I will probably too be the one who does the work. > > In the long run I expect the following additional interfaces used by > > GNOME or one of its components: > > > > - I am working on two more mechanisms generalizing control of the system > > locale and system clock/timezone for use in the control center and by > > other UIs. > > Reducing this to a yes-or-no-feature view: distro/kernels without > systemd will have to apply a (big?) patch gnome-control-center in order > to provide the ability to change locale and time settings. Is this > correct? No. As I tried to make clear a gazillions of times: the mode of cooperation with other kernels is sharing interfaces, not code. i.e. other OSes can reimplement the bus interface. Bastien's g-c-c stuff uses the D-Bus interface, and if they reimplement that they can benefit from the same features. It's all documented: http://www.freedesktop.org/wiki/Software/systemd/hostnamed There's nothing systemd specific in that iface. And as mentioned, other Linux distros can compile systemd and strip everything but hostnamed and friends. I wrote that explcitly in my original mail. > Also, if I haven't misunderstood, 'cause you will not maintain a systemd > version for non-linux kernels, if FreeBSD (just and example) will switch > to systemd, FreeBSD developers will have to maintain their own forked or > patched version of systemd, haven't they? No. It makes no sense running systemd on the BSDs. I don't think anybody who knows systemd and the BSDs would seriously suggest anything like this. See this mail of mine for an explanation: https://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00447.html Focus is on sharing interfaces, not code. > > - gdm will interface with the new CK-replacing code I am working on. > > > > http://lwn.net/Articles/441328/ > > Same previous yes-or-no question (to simplify: no systemd, no login), > plus I suppose this bond between systemd and gdm will add another -1 to > lightdm. Well, the interfaces we provide in systemd are not bound exclusively to be consumed by gdm. The KDE folks for example are very welcome to support the same functionality for KDM, and use our interfaces. And that's true for any other kind of DM too. > > - Later on I hope that we can use per-application cgroups to create > > reliable mapping between desktop files and processes. (i.e. place each > > app in a cgroup and name it after the .desktop file), integrated into > > the systemd cgroup hierarchy, so that this can be used for g-s and > > other UIs to relate desktop files to processes. > > Is this the only way to create a relationship between processes > and .desktop files? For example, another solution to this feature seems > to be BAMF (https://launchpad.net/bamf/ ), and I remember it was > suggested as a viable solution (maybe by vuntz?). Advantages? > Drawbacks? I have not looked in detail into BAMF. I want the definition of an app in the OS, not as glue code bolted on top that works with heuristics. > Do you think systemd approach will be used by or can be shared to > non-GNOME stuff too (for instance firefox or libreoffice or qt apps and > so on)? Yes, it pushes the definition of an app into the kernel, via cgroups. That is compatible with all kinds of apps. > > systemd is Linux-only. That means if we still care for those non-Linux > > platforms replacements have to be written. > > So, IIRC, the release team will have to choose between "have > features" (or enhancements to currently available features) and "create > a lockin" (or something that, at least currently, resembles a lockin). Using "lock-in" as word is inappropriate here. It's free software. That per definition doesn't cause lock-in. It's like it always is: some features are available on some systems only, but the others can catch up if they want. > Do you think we (release team) should follow a technical approach or a > "political" approach to this question? Why? I dont understand the question. I tried to outline the mode of cooperation I am suggesting on these interfaces. > We are still at 3.2 release and systemd is a young project and not > widely adopted solution. Any special reason to introduc
Re: On the Interaction with the design team
On Fri, 2011-05-20 at 09:52 -0400, José Aliste wrote: > Hi, > > I have a simple question (hopefully ddl is the right mail list for > this): how are we supposed to interact with the design team? it seems > that the best way is contacting them through irc in #gnome-design, but > what about Gnome bugzilla? Does setting a keyword or something makes > the design team in the CC of a bug or something so we can get UX > advice from them? > > I understand that dealing with design of new features, hanging in IRC > is best as it is faster to interact this way, but there are a bunch of > bugs in Evince that need a thumbs up/thumbs down from the design team > and I d like to know which is the best way of interacting so we can > get these fixed/or wont fixed but with a clear statement from UX point > of view why we are doing so. (and having a page, that probably exists, > explaining the interaction between different teams would be also > great) The easiest is to add the "ui-review" keyword, and poke people on #gnome-design. Make sure that your bugs include clear before/after details, even screenshots if the feature is trivial to implement, mockup-able, or already available as a patch. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On the Interaction with the design team
Hi José, On Fri, 2011-05-20 at 09:52 -0400, José Aliste wrote: > Hi, > > I have a simple question (hopefully ddl is the right mail list for > this): how are we supposed to interact with the design team? it seems > that the best way is contacting them through irc in #gnome-design, but > what about Gnome bugzilla? Does setting a keyword or something makes > the design team in the CC of a bug or something so we can get UX > advice from them? > > I understand that dealing with design of new features, hanging in IRC > is best as it is faster to interact this way, but there are a bunch of > bugs in Evince that need a thumbs up/thumbs down from the design team > and I d like to know which is the best way of interacting so we can > get these fixed/or wont fixed but with a clear statement from UX point > of view why we are doing so. (and having a page, that probably exists, > explaining the interaction between different teams would be also > great) > > Greetings, > > José #gnome-design is good; so is the usability list. The ui-review Bugzilla keyword gets used in GNOME Shell and the control center. We could try that here too. Allan -- Blog: http://afaikblog.wordpress.com/ IRC: aday on irc.gnome.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
On Thu, 2011-05-19 at 13:10 -0300, Evandro Fernandes Giovanini wrote: > Em Qui, 2011-05-19 às 15:15 +0200, Lennart Poettering escreveu: > > On Thu, 19.05.11 00:50, Sergey Udaltsov (sergey.udalt...@gmail.com) wrote: > > > > > > > > > I think the best way to save resources is not to run anything. For stuff > > > > like hostnames/locale/time which is used only every other moonphase > > > > having tiny single-purpose mini-services is perfectly appropriate. I > > > > don't think there would be any benefit in merging these mini daemons > > > > into one. Au contraire, I'd guess you'd waste even more resources with > > > > dlopen() and friends. > > > Can all those services be standardized using DBus interfaces (DBus > > > activation if necessary)? IMHO that's the only way to remain friendly > > > to non-linux OSes, not having any bits of systemd (or distros that are > > > not using it)? > > > > Some can. Not all. > > > > The hostname mechanism is explained in very much detail here: > > > > http://www.freedesktop.org/wiki/Software/systemd/hostnamed > > > > As suggested a couple of times I believe the mode of cooperation with > > the Solaris/BSD folks here should be to share those interfaces, not the > > code behind it. > > > > Something similar is true for the locale/timezone/time mechanisms. > > > > Would you propose a specific set of interfaces as blessed external > dependencies instead of systemd entirely? I believe that would make this > discussion quite a bit simpler. The flames have died down now. I'd like to discuss this bit productively. I don't think Lennart is being unreasonable in suggesting that underlying systems share interfaces. It's what we do right now with really core stuff (e.g. libc), and it's what we do with other desktops for certain D-Bus interfaces. I think Evandro's proposal is fair as well. We could set up a wiki page listing D-Bus interfaces we expect to be available. And not just for systemd-related things. Don't like PackageKit? Fine, whatever, but we expect you to make your stuff implement this interface. Then there's the non-D-Bus API. Function calls, file format and layout, command-line tools, unit names. (I'm using API broadly to mean anything we expect to be true of the system.) Can we list exactly what we expect to work for the features we need? That way, if anybody wants to do the porting work, they know exactly what they need to do. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
On Fri, May 20, 2011 at 10:37 AM, Shaun McCance wrote: > Can we list exactly what we expect to work for the features we > need? That way, if anybody wants to do the porting work, they > know exactly what they need to do. I've already pointed this out http://live.gnome.org/PortabilityMatrix which can be taken as a starting point. It can certainly be improved upon, but there should be no illusion that writing a 'how to port gnome to your OS in 10 easy steps' manual will be a huge undertaking, for very modest gain, and it will be more or less outdated fairly soon. And it is extra work that distracts from the core mission: writing something that actually works, and is awesome. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.2 features: login screen
On Fri, May 20, 2011 at 9:44 AM, Luca Ferretti wrote: > If you missed the point, I'm asking about planned behavior and features > for this first time assistant: > A. will it be only for "master" user or for all users? > B. will it allow some kind of customization by > vendor/distro/whatever? > > I suppose those are good question about a new feature like this. Let me answer them. A. The design is to run this only for the initial setup, when no users exist yet. The large majority of systems nowadays are single-user, anyway... B. Not planned, no. This is intended to configure a handful of essential things, not an open-ended list of things you might want to set up if happen to know about them. If twitter-esque web services become supported by 'online accounts', that would make it possible for gwibber to pick up the configuration from there. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.2 features: color management
On 20 May 2011 13:38, Richard Hughes wrote: > When I've pushed some of the initial code into gnome-control-center > and gnome-settings-daemon I'll post some screenshots of what it looks > like. Okay, I've pushed the code to g-s-d and g-c-c just now. Thanks to Bastien and Matthias for the super-quick reviews! You can see a screenshot here: http://bugzilla-attachments.gnome.org/attachment.cgi?id=188165 If you're testing the new code, be sure to grab colord from git master, as Bastien wanted me (correctly) to push some of the helper code down into libcolord. Also, don't try to calibrate just yet, it's known broken. When I've untangled gnome-color-manager the gcm-prefs binary will be deleted, and a gcm-calibrate binary will show up for g-c-c to use. If you've got comments about the UI, please either grab one of the guys in #gnome-design, or one of the gnome-color-manager developers in #gnome-color-manager. Thanks, Richard. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.2 features: login screen
On Fri, May 20, 2011 at 8:39 AM, Josselin Mouette wrote: > Le vendredi 20 mai 2011 à 08:02 -0400, Matthias Clasen a écrit : >> - An 'initial-setup' tool. The goal here is to allow setting up a few >> essential things on a new system before you start to use it for the >> first time. > > Please don’t do this. It would merely duplicate the functionality > already in the installer. The best argument for having this as part of the OS is for the live CD scenario. You might as well type in your username each time if you have to pick language etc. too. And once you've done this, then you don't need to create a user in the installer, because we can just take the one you made at bootup. It's almost like everything would be integrated and actually make sense! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.2 features: login screen
Le vendredi 20 mai 2011 à 11:11 -0400, Colin Walters a écrit : > The best argument for having this as part of the OS is for the live CD > scenario. You might as well type in your username each time if you > have to pick language etc. too. Hi, The liveCD or the installer don't require any output, taking the Ubuntu example loco team distribute localized versions of the CD with the right locale by default, the liveCD autologin, you click on the installer, select your location and partitions then the installation start and you can deal with the customizations while the copy is happening. Having it done while the system is working is a time win over what you suggest Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
On Fri, 2011-05-20 at 10:49 -0400, Matthias Clasen wrote: > On Fri, May 20, 2011 at 10:37 AM, Shaun McCance wrote: > > > Can we list exactly what we expect to work for the features we > > need? That way, if anybody wants to do the porting work, they > > know exactly what they need to do. > > I've already pointed this out http://live.gnome.org/PortabilityMatrix > which can be taken as a starting point. It can certainly be improved > upon, but there should be no illusion that writing a 'how to port > gnome to your OS in 10 easy steps' manual will be a huge undertaking, > for very modest gain, and it will be more or less outdated fairly > soon. And it is extra work that distracts from the core mission: > writing something that actually works, and is awesome. I didn't suggest a lengthy tutorial or a support matrix. Just a list of interfaces we use. It takes some work, but it doesn't have to take nearly as much work as you're suggesting. 1. "I need sd_foo_interface to implement foo feature" 2. Write code 3. git commit && git push origin master 4. echo sd_foo_interface >> http://live.gnome.org/Interfaces -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.2 features: login screen
Hi! > B. Not planned, no. This is intended to configure a handful of > essential things, not an open-ended list of things you might want to > set up if happen to know about them. If twitter-esque web services > become supported by 'online accounts', that would make it possible for > gwibber to pick up the configuration from there. I have very mixed feelings about not allowing any customization here, especially for web-services where we mostly talk about proprietary web services: a) Who decides which to include? Why would we include Google and Facebook but not Bing or UbuntuOne*? This is one of the points Microsoft got sued badly by the EU in the past. * Don't take this examples to literally... b) There might be a lot of people that take integration of some services as part of the business. That doesn't mean we should encourage it but even manufacturers that would want to preinstall some Linux distribution would likely want to have some customization here. Personally I also don't think that the network panel is very useful. There are basically three cases to consider here: a) Wired connection - should automatically connect with DHCP b) Wireless connection - I think NetworkManager covers this pretty nicely in the UI. The network menu could even be automatically shown on first login when no network is connected. c) Scary (static IP, Proxy, whatever) setups - we don't want to provide an UI in the startup-wizard, do we? Regards, Johannes 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: 3.2 features: login screen
Hi, On Fri, May 20, 2011 at 11:21 AM, Johannes Schmid wrote: > Hi! > >> B. Not planned, no. This is intended to configure a handful of >> essential things, not an open-ended list of things you might want to >> set up if happen to know about them. If twitter-esque web services >> become supported by 'online accounts', that would make it possible for >> gwibber to pick up the configuration from there. > > I have very mixed feelings about not allowing any customization here, > especially for web-services where we mostly talk about proprietary web > services: > > a) Who decides which to include? Why would we include Google and > Facebook but not Bing or UbuntuOne*? This is one of the points Microsoft > got sued badly by the EU in the past. > > * Don't take this examples to literally... It's just not that simple. I briefly explained the problems here http://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00267.html TL;DR : - The technical problems involve managing N times M times P codebases - There might be really nasty Terms Of Service issues - I expect 3.2 to only support Google, Yahoo providers - I expect 3.2 to only support Mail and Calendar services After 3.2 we can add more providers and more kinds of services. I'm still working on this. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.2 features: login screen
Matthias Clasen (matthias.cla...@gmail.com) said: > Let me answer them. > > A. The design is to run this only for the initial setup, when no users > exist yet. The large majority of systems nowadays are single-user, > anyway... OK, but that does make me wonder about when this isn't the case. The flow appears to be: Initial state: a system with no users a) InitialSetup runs b) Create first user c) Configure first user's settings d) First user has full session e) First user creates additional users in control-center Questions: 1. How is 'c)' different from the existing control panels (including new ones for GOA)? Do they share any code or implementation? If they don't, how do we document for new users that to change these settings they go through a different interface than they did for initial setup? 2. Similarly, how is 'e)' different than the current user add screen? How are additional users expected to configure this information for their login if they are created in this manner? 3. Given the 'initial setup' sort of idea, is there going to be a 'reset to factory defaults' button somewhere else? Bill ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
Le vendredi 20 mai 2011 à 10:37 -0400, Shaun McCance a écrit : > I think Evandro's proposal is fair as well. We could set up a > wiki page listing D-Bus interfaces we expect to be available. > And not just for systemd-related things. Don't like PackageKit? > Fine, whatever, but we expect you to make your stuff implement > this interface. PackageKit is a good example of why this is not always a great idea. If you design an interface based on a given system, you might make assumptions that make it hard to adapt to other systems. I don’t think this approach is bad per se, but it requires extra care while designing the interfaces, and checking how they would be ported to other OSes, even without actually doing the job. -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.2 features: login screen
On Fri, May 20, 2011 at 3:32 PM, Bill Nottingham wrote: > Matthias Clasen (matthias.cla...@gmail.com) said: > > Initial state: a system with no users > a) InitialSetup runs > b) Create first user > c) Configure first user's settings > d) First user has full session > e) First user creates additional users in control-center > > Questions: > > 1. How is 'c)' different from the existing control panels (including > new ones for GOA)? Do they share any code or implementation? > If they don't, how do we document for new users that to change these > settings they go through a different interface than they did for > initial setup? It is different from the control-center in so far as it is a guided setup, asking you the handful of questions you need to answer before you can get going. The control-center is not offering you that guidance. In terms of what you can configure, the initial setup is a very tiny subset of what you can do in the control-center. And it is supposed to remain a proper subset; we want to avoid the install-time-only configurability that we've seen in the past with 'fat' installers. What is shared here is a) the system and session services that are used and b) the general user experience - e.g. the network list uses the same icons and appearance as the combo in the network panel, and the timezone map is the same widget you see in the datetime panel. As far as actual code sharing goes, currently some bits and pieces are copied. Some of it (e.g. the map widget) will end up in shared libraries (see ongoing discussion on the control-center list), but I don't see that as an urgent priority. > 2. Similarly, how is 'e)' different than the current user add > screen? How are additional users expected to configure this information > for their login if they are created in this manner? Additional users can use the control-center to set up the account, as things currently stand. It is conceivable that one could write a welcome assistant for additional users that does some of the same things (and probably shares some of the code), but that's not part of the current design. And considering that most systems are single-user, and additional users are much less likely to be 'alone with the new toy', it seems a much lower priority. > 3. Given the 'initial setup' sort of idea, is there going to be a > 'reset to factory defaults' button somewhere else? I don't think we need one, really. Do you ? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
On Fri, 2011-05-20 at 23:12 +0200, Josselin Mouette wrote: > Le vendredi 20 mai 2011 à 10:37 -0400, Shaun McCance a écrit : > > I think Evandro's proposal is fair as well. We could set up a > > wiki page listing D-Bus interfaces we expect to be available. > > And not just for systemd-related things. Don't like PackageKit? > > Fine, whatever, but we expect you to make your stuff implement > > this interface. > > PackageKit is a good example of why this is not always a great idea. If > you design an interface based on a given system, you might make > assumptions that make it hard to adapt to other systems. > > I don’t think this approach is bad per se, but it requires extra care > while designing the interfaces, and checking how they would be ported to > other OSes, even without actually doing the job. You don't mention specific problems. I assume you mean the issues with user interactions when installing: http://www.packagekit.org/pk-faq.html#user-interaction I don't believe this is a case of developers not having researched what different systems do. Rather, I think it's a case of making a conscious design decision about how we think users should interact with computers running GNOME. Understand that GNOME 3 is design-focused: We create a coherent design for users, then we figure out what technology we need to make that design happen. Some people seem to want to go the other direction: See what technology we have, and figure out what kind of design we can bolt on top of it. I think it is absolutely fair to ask GNOME developers to document what they expect of the system to achieve their designs. I do not think it's fair to ask them to compromise their designs because some technology stack behaves differently. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
