Re: Requiring systemd for the gnome-settings-daemon power plugin
Hey, On Mon, Oct 22, 2012 at 11:18 AM, Brian Cameron brian.came...@oracle.com wrote: Most readers would likely need to review the code to understand what specific power features are actually being described here or why they might need logind. Most rows in the table are like this, so this matrix is only a very useful guide if the reader has many hours to invest to understand how the information applies to them. To me, the matrix looks more like a draft of an outline to a guide, but it is a start. You are talking about shipping a *complete* and *free* (libre *and* gratis) graphical desktop environment and you're complaining that you have to spend a couple of hours *reviewing* the code and/or turning off the features that you *did not* participate in developing because you choose to use a different OS than the people who actually *did* spend time working on the feature? I don't think that's fair at all - and I really have to constrain myself to not use stronger language here. Instead, may I suggest getting involved early and voicing your concern *during development* so we can either add an abstractions (such as e.g. GVolumeMonitor, GDrive, GVolume, GMount) or ifdefs or whatever [1] and avoid situations like this? Surely, the way it needs to work in GNOME is that if distributors show up and do portability-work (and it's good enough) [2] it will get merged. But it involves actually showing up and doing the work and not just sending e-mail. But please don't expect others to port GNOME to run on your OS. David [1] : Abstractions can happen at several levels: D-Bus interfaces, Library APIs, #ifdef etc. I think it's up to the maintainer of the module in question to decide how to handle portability. [2] : FWIW, GVolumeMonitor and related APIs is a *great* example of how to handle portability. We've kept the same application-level API since the beginning and have managed to just swap the implementation out (hal, udisks1 and now udisks2) without disrupting any application. And we've made sure it worked on old-skool Unix and the BSDs by having a 'unix' (e.g. fstab/mtab based) backend as well. But as any GIO/GVfs developer will tell you, the price is pretty high but in terms of code complexity and also there's a hit in runtime/login performance because of its distributed nature. There's another important lesson to be learned here: portability and abstractions on the GNOME-side is not only about OS portability - it also makes it easier to revamp some of the underlying subsystems ... e.g. I could never have done the hal-udisks1-udisks2 move without something like GVolumeMonitor so, in retrospect, it turned out to be a good idea that such abstractions were around. But they come at a cost. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
Hey, On Mon, Oct 22, 2012 at 1:24 PM, Brian Cameron brian.came...@oracle.com wrote: I have heard about this couple of hours. Is it even possible to build the GNOME stack in 2 hours if you run into no problems? That's not the point. The point is that adapting GNOME to some OS such as Solaris, Fedora, Ubuntu, OpenBSD or whatever is likely to take a lot more effort than a couple of hours each release. The point is that it's not fair to anyone if a *OS vendor* to expect this to be easy and complain if it's not saying there's not enough documentation or it doesn't fit in with our schedule. I have, over the past years, tried several times to discuss issues surrounding portability. For example, as GDM maintainer I strongly recommended against supporting ConsoleKit as a hard dependency in the first place. In hindsight, I think adopting and throwing away ConsoleKit was not the best decisions. In the situations where I did voice my concerns during development, I think we have seen that these two ideas 1. make GNOME depend on a system daemon and port it everywhere (HAL, ConsoleKit, for example) 2. make GNOME depend on a system-bus based D-Bus API and make it work with several implementations (systemd, upstart, for example) do not work well in practice. But we didn't know back then, things like HAl and ConsoleKit all sounded like great ideas! The thing is that these are the kind of mistakes that we as a project had to make *ourselves* - it's not something you can just learn. In that way, failing is *good* - you learn new things from it. As a project, I think GNOME learnt a bunch from it. FWIW, what seems to work a lot better is to do the abstraction on the GNOME-side, e.g. GVolumeMonitor, GNetworkMonitor and so on and then leave it to OSes to fill that in. I did not get the impression that my concerns generated much response. Dude, that happens to all of us at some point. I have personally done a fair share of porting work over the years. I do not just send emails. Have we not met? We have. But I was making a more broad comment but of course: your effort is very much appreciated. As is, for example, Antoine's work on OpenBSD portability. Or the work going into taking advantage of certain systemd features. Work on GNOME is *always* appreciated and we don't discriminate based on what OS your are using. But it does require the work to happen - not so much a long thread about how it's so much work and how it's hard and so on. But please don't expect others to port GNOME to run on your OS. I was never suggesting that any others do any sort of port for anyone. I was only highlighting that the lack of documentation makes things slow. I am sure that we can improve the situation with some effort. Many mature products provide docuemntation to help developers make a transition when there is a new major release. I think GNOME is weak in this area. The fact that GNOME's developer documentation and GUI building tools are weak is not a new topic. Last year I remember people talking about how to catch up with KDE in this regards, for example. Unfortunately, I do not think we have yet even accomplished this more modest target. Nah, I really don't think GNOME should be that complicated - we're a desktop, we're a user experience - we should be more fluid, more agile than your grandfather's SDK porting kits with committees (or, worse, mailing lists) having to approve this or that thing. I mean, it's fine to have this for GLib and GTK+ (and we do [1]) but I wouldn't want to see us spend that amount of time on GNOME proper - I'd much much rather see us spend time on improving GNOME or adding cool features. David [1] : http://developer.gnome.org/gio/unstable/migrating.html [2] : http://developer.gnome.org/gtk3/unstable/migrating.html ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
Hey, On Mon, Oct 22, 2012 at 2:05 PM, Brian Cameron brian.came...@oracle.com wrote: Right. So, you probably are not surprised that things are moving along slowly either. :) Actually I'm quite excited about the development pace for GNOME nowadays - there are lots of cool *user-visible* features landing in new releases. The fact that it's hard for some OSes to keep up is an interesting indicator that the focus in GNOME is more on features than (boring [1]) abstraction / portability work. I'm not saying that's 100% right - in fact, my previous mails calls for help in that area - but as an end-user, I'm pretty excited about GNOME. I would definitely not characterize it as moving along slowly. As a developer (and working for an OS vendor), I *do* want more OS vendors to step up and intensify their participation in the project. Yes, more participation from several different OS vendors might slow down feature development a bit (for example, landing a *simple* library-based abstraction for systemd's logind mechanism), but at the end of the day, it's probably going to be a win for everyone. David [1] : I'm entitled to label it this way because I've done a lot of this kind of work - it really is not very exciting or sexy :-) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.5.91 second beta release
Hi, On Wed, Sep 12, 2012 at 1:10 PM, Ray Strode halfl...@gmail.com wrote: See http://www.gnome.org/getting-gnome/ for info on how to try the ISO out with a usb stick. In addition to 'sudo dd ...', it might be worth pointing out that you can use the Restore Disk Image feature in GNOME Disks for this operation - for more information see my Google+ post about it https://plus.google.com/u/0/110773474140772402317/posts/WEBSpELokqf David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: udisks2 [WAS: Re: datetime: Remove datetime D-Bus mechanism]
On Mon, Jan 23, 2012 at 4:50 AM, Olav Vitters o...@vitters.nl wrote: On Sat, Jan 21, 2012 at 04:13:58PM -0500, David Zeuthen wrote: Not that I know of, no. But I expect that they will make use of their abstraction layer thingies. I assume they're aware that it is changing? I think so. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: udisks2 [WAS: Re: datetime: Remove datetime D-Bus mechanism]
On Mon, Jan 23, 2012 at 4:14 AM, Frederic Peters fpet...@gnome.org wrote: David Zeuthen wrote: @David: could you confirm this? And do you have any ETA for a udisks2 tarball? There is one at http://udisks.freedesktop.org/releases/ http://www.freedesktop.org/wiki/Software/udisks still points to http://hal.freedesktop.org/releases/, could you update that page? Done, thanks. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: udisks2 [WAS: Re: datetime: Remove datetime D-Bus mechanism]
Hey, On Mon, Jan 23, 2012 at 10:31 AM, Tomas Bzatek tbza...@redhat.com wrote: David, any plans for extending udisk2 support to non-udev/non-linux systems? No plans. In fact, I would recommend that non-Linux simply writers their own GVfs volume monitors instead if the 'unix' backend isn't good enough - much easier for everyone. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: udisks2 [WAS: Re: datetime: Remove datetime D-Bus mechanism]
Hi, On Sat, Jan 21, 2012 at 8:04 AM, Frederic Peters fpet...@gnome.org wrote: Johannes Schmid wrote: Short note: I removed the udisks and upower rows as they don't follow the system of showing the part of GNOME using some technologie. Instead those are referred to by the gnome-disk-utility and gnome-control-center/power rows which is IMHO the correct way. Speaking of udisks, gnome-disk-utility has now been switched to use udisks2; Note that distributors are free to continue using the old udisks1 (and udisks2 is parallel installable with udisks1) with gnome-disk-utility 3.2.x series as long as they want. I can only guess gvfs will follow. And gvfs will continue to support the existing gdu and hal backends. So there is really no pressure to switch to udisks2 ... @David: could you confirm this? And do you have any ETA for a udisks2 tarball? There is one at http://udisks.freedesktop.org/releases/ Cheers, David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: udisks2 [WAS: Re: datetime: Remove datetime D-Bus mechanism]
Hey, On Sat, Jan 21, 2012 at 1:45 PM, Michael Biebl mbi...@gmail.com wrote: Seing that KDE still uses udisks1, I'm wondering what happens if one compiles gdu/gvfs against udisks2 and starts a KDE app within GNOME. I assume this will fire up udisks-daemon 1 and so both udisks-daemon 1 and 2 are running at the same time. Will they step on each others toes in this case? Nope, works perfectly fine, won't step on each others toes (because both daemons are written to listen to changes done not by themselves ... mostly so the desktop reacts if you e.g. mount something from the command-line). A big part of this puzzle, btw, involved pushing media polling into the kernel ... if we didn't have this then both daemons would be removable devices. Fortunately, none of them do this now. What is your plan for Fedora (given that you also have a KDE spin). Will you ship both udisks versions in the archive? udisks2 for GNOME 3.4 and udisks1 for KDE? Both udisks1 and udisks2 will be available in the Fedora repos - we're hoping to only ship udisks2 on the GNOME live cd. I don't know what the KDE guys are doing, I don't follow KDE closely. I'll probably retire udisks1 after F17 and then either it dies or someone needing it will pick it up. Do you know of any efforts of getting KDE/Solid ported to udisks2? Not that I know of, no. But I expect that they will make use of their abstraction layer thingies. @David: could you confirm this? And do you have any ETA for a udisks2 tarball? There is one at http://udisks.freedesktop.org/releases/ How feature complete do you consider this 1.90.0 release? What is missing compared to udisks1? Are any major disruptive changes still planned before a 2.0 release? It's pretty feature complete as far as what was planned - I don't foresee any big changes apart from bug-fixing. Still holding the right to break ABI still, but I'm not planning to. Btw, one thing that we won't support in udisks2 is the various RAID and LVM bits ... well, we'll still show the fake block devices, such as the /dev/vg_x61/lv_* ones here http://people.freedesktop.org/~david/gdu2-self-test-failed.png we'll even show the nice names instead of the /dev/dm-N non-sense names. But we're not going to provide any facilities to manage LVM or MD-RAID like we tried in the old Palimpsest version. But we'll of course keep the UI up to date if you use mdadm(8) or one of the LVM tools from the command-line. There's also support for a lot of other nice features that we didn't have with udisks1 such as fstab and crypttab editing, support for easily setting up loop devices, disk imagine (create/restore) which IMO are more important. I'll blog about all this next week... Cheers, David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts extensibility
Hi, On Sat, Oct 8, 2011 at 12:11 PM, Ted Gould t...@gould.cx wrote: So to be clear, you see GOA's configurability to be in setting up new account groups, but new protocols. So I could add Corp. Account but if my corp. uses a protocol that GNOME OS doesn't use otherwise, I couldn't add this. Trying to understand what configurability you expect in the future. The way to look at GOA is that it's just one provider of accounts. As I said, GOA is by no means a substitute for having a separate way to configure an app for accounts - if it was, then GOA would be a choke point in this way: it just makes no sense to add protocol-support in both the app and in GOA to make things work - you end up with ugly dependencies between the app, libgoa and the running goa-daemon(8) instance. Which makes it really hard to get anything done. So just from a technical point of view the I want to use GOA to configure everything is a non-starter, I think. You should think of GOA as something that the app can optionally depend on to make using 'suites' of services (e.g. Google, Yahoo) just work in the sense that you logon once and then the auth token is used for all services, e.g. mail, chat, calendar etc. And no-one says that only GNOME apps (such as Evolution) can use this - no one is preventing e.g. Thunderbird from consuming the same kind of data. The other thing is that we do not want the UX in the Online Accounts preference pane to look like this http://people.freedesktop.org/~david/lots-of-account-types-that-i-don't-know-about.png Not that there's anything per-se wrong with that kind of UI in Empathy (the same way there's nothing wrong with all the Chrome you find in e.g. Gimp) - we just don't to expose the user to it if we can avoid it. The idea of Online Accounts has been from the start that this is something the user sees in either the OS installer or as part of some Initial Setup experience, see e.g. https://live.gnome.org/GnomeOS/Design/Whiteboards/InitialSetup So you ask about extending GOA and I've already explained a bit about that upthread. It's not that I'm 100% opposed to it, heck as I said we used to read config files, and double-plus-heck, the code is already using gio extension points, see http://developer.gnome.org/goa/unstable/GoaProvider.html#GOA-PROVIDER-EXTENSION-POINT-NAME:CAPS http://developer.gnome.org/goa/unstable/GoaProvider.html#goa-provider-get-for-provider-type we just don't read any GIO modules just yet. As I said upthread, the only reason this is so is basically because a) providing a stable API for extensions is expensive; and b) providing a stable config file format is also expensive; and c) it's too easy to abuse to create substandard UX in the Online Accounts preference pane. Well, where to go from here? a) and b) will clearly be non-issues around 3.4 or 3.6 as things stabilize [1]. It's more c) I'm concerned about. To resolve this we need to work with the designers to make sure that the UX can scale in the presence of many different account types. Either way, I don't get why you are so concerned about whether GOA can be extended. If you buy into the idea that apps will always need to have a separate panel for non-mainstream accounts then... then the app can provide the extension point and config-file merging from .d-directories. David [1] : note that we said the same about GVfs and GVfs backends are still private GNOME API 3 years later. Which turned out to not really be a problem even though everyone whined about it about the fact that there is no stable GVfs API. But it works really well for GVfs, heck we got all the interesting parts _in the GVfs tree_ instead of them being random 3rd party things seeing less testing. It's similar to how the Linux kernel works. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts extensibility
Hey, On Mon, Oct 10, 2011 at 11:10 AM, Ken VanDine kvand...@gnome.org wrote: We discussed this with twitter, and they agreed that including the API key in the packaging instead of in the upstream source was good enough separation for them. So for example, in the Ubuntu package we include the Ubuntu API key for twitter. And we recommend all distros to do the same. It would be helpful if you could include the GNOME Foundation, specifically our Executive Director, in these discussions as one of the questions we are currently dealing with is exactly how to manage API keys. As I've said, it's something that we're blocking on in GOA... in fact, it's why GOA only supports Google because Google still works without API keys. (FWIW, my view is that in order for GNOME to keep a straight face, free software-wise, and for things like jhbuild to work, we need GOA's configure.ac file to include the API keys for each provider and the Foundation will need to manage the keys. Whether each downstream patches in its own keys (for one reason or another) and what the Foundation's advice in this matter is (do we encourage downstream's to use the Foundation API keys?) is a separate question.) Thanks, David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts extensibility
Hi, On Fri, Oct 7, 2011 at 9:05 AM, Ted Gould t...@gould.cx wrote: IMHO, the problem with GOA is its lack of extensibility. So adding something like a corporate account type is difficult if not impossible. For instance, if was foo corp, and we had internal mail, jabber and status.net services -- I'd like to provide one way to provide this configuration and have one place for users to set up their accounts. I think handling this use case could provide some guidance for where GOA could go in making users who are corporate environments lives easier. If you examine the GOA project and its git log, we actually did use to read config files from /etc/goa-1/config.f and ~/.config/goa-1.0/config.d (or something similar to that). But I ripped this out as I didn't want to commit to a config file format for 3.2. Why? Because it's never smart to paint yourself into a corner for new stuff. But no-one says we can't do it for 3.4 or 3.6 or whatever. In particular, having 1. a stable config file format; and 2. .d directories in /etc and $HOME; and 3. something $USER expansion in config files combined with the idea of supporting generic IMAP/SMTP/XMPP/Caldav configurations, see https://bugzilla.gnome.org/show_bug.cgi?id=661117 that Patryk filed on my request... then... then GOA can be pretty nice from a corporate point of view. Because with that the you'd just drop a single config file in /etc/goa-1/config.d/mail.conf specifying the $u...@company.com for email, something else for XMPP and so on. But please note: all this has absolutely nothing to do with Ken's rant. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts extensibility
Hi, On Thu, Oct 6, 2011 at 12:52 PM, Ken VanDine kvand...@gnome.org wrote: I really want to get rid of gwibber-accounts for configuring accounts in Gwibber. It makes sense to use GOA for this, I don't think it necessarily does, no. See below. however gwibber supports quite a few social networks as well as supporting third party service plugins. So anyone can add support for a new social network without changing gwibber. So to transition to using GOA, we would need to include support for all the social networks Gwibber supports out of the box, and provide a way for third party developers to include the necessary provider for GOA. This really won't be manageable if all the providers need to be merged upstream with GOA and included in a release. Thoughts? Well, until we've figured out a story in GNOME for how social networks are integrated, it just doesn't make sense to add this to GOA. The more general observation (of which the above is a specialization of) is that we do not add support for providers P (e.g. Google, Facebook) or services S (e.g. Documents, Mail, Chat, Calendar, Contacts) until 1. we know how it's going to be used in a GNOME release; and 2. there is something in the GNOME release using it. Basically: you need to work with the GNOME Designers on figuring out how social networks fit in. For GNOME 3.2 we have the following users: - Empathy / GNOME Shell (Chat) - Evolution (Mail, Calendar) - GNOME Contacts (Contacts) - GNOME Documents (Documents) and we still only support Google as a provider. Why? Because Google is right now the only provider where a) we can use anonymous API keys; and b) we have support for Google in the above-mentioned apps The other problem is how to handle API keys. As I have mentioned before on this list and elsewhere, a couple of months ago I sent a long mail with legal questions to the GNOME Foundation and I'm still waiting on a response. Basically, we want to be able to legally ship API keys along with GOA. So it boils down to this: even if we had all the protocol support for, say, Facebook in, say, GNOME Contacts (through libfolks) and Empathy (through Telepathy) we would not be able to turn it on because of unresolved API key and legal questions. Are there plans for making service providers in GOA pluggable? Not at this point, no, and probably not in the future either. Why? Two reasons I. Adding support for a provider P, currently means making code-changes to all of the GNOME apps using its services.. because most of the time standard standardized protocols are not in use. For the few cases where it uses a standard protocol (such as XMPP and IMAP/SMTP) we could support pluggable providers. For example, we could, presumably, read plug-in files from some directory so we could list 200 different XMPP chat services or 200 different IMAP servers. That that no-one ever heard about. But would we want the user to see this? The answer is: not in GOA. But see II. below II. To avoid user confusion we only want the major online services in GOA. Support for more specialized protocols/services should happen in each separate app - that's why, for example, that Empathy still has a preferences menu so you can add support for e.g. ICQ, Zephyr and other fringe chat services and protocols. And that's also why you still have support in Evolution for manually adding IMAP/SMTP servers. I will try and add some of these guidelines (or rules if you want) to the GOA documentation, see http://developer.gnome.org/goa/unstable/ for what it looks like right now. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts extensibility
Hi, On Thu, Oct 6, 2011 at 2:10 PM, Steve Frécinaux nudr...@gmail.com wrote: On 10/06/2011 07:40 PM, David Zeuthen wrote: II. To avoid user confusion we only want the major online services in GOA. Support for more specialized protocols/services should happen in each separate app - that's why, for example, that Empathy still has a preferences menu so you can add support for e.g. ICQ, Zephyr and other fringe chat services and protocols. And that's also why you still have support in Evolution for manually adding IMAP/SMTP servers. What about free (or not free) services you can install on your own box but would still provide services for many different programs? I'm thinking about owncloud, for instance, which provides document storage, calendar, bookmarks, etc. Sure this is not a well known service, but yet I think many would like to be able to add such services, due to our natural love of freedom and not promoting big companies without alternatives. I agree it would be nice if the free software community could come up with a credible alternative to Google, Yahoo or Microsoft's Live to name just three. And I definitely think if such a credible alternative were to surface we should definitely support it in GNOME along the same lines of the non-free ones, perhaps even giving it special treatment because its free. Whether OwnCloud specifically is this project remains to be seen - but see https://bugzilla.gnome.org/show_bug.cgi?id=660573 for the request to add OwnCloud support to GOA (the reason I haven't replied to that bug yet is that I want to get the guidelines I gave upthread into the goa docs). David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts extensibility
Hi, On Thu, Oct 6, 2011 at 2:30 PM, Ken VanDine kvand...@gnome.org wrote: Sorry, not trying to sound harsh here but I couldn't find a better way to say this. Basically you are saying that GOA isn't really an open technology to help consolidate user's online accounts, it is only to help consolidate accounts for blessed GNOME apps? This doesn't really help users in the big picture, but I guess the design team makes those decisions. Does this mean third party developers shouldn't try to leverage GNOME as a platform anymore? Maybe that is a topic for another thread, as much as I love GNOME, it is becoming harder and harder to develop for. I miss the days when GNOME was a platform, I hope there is a way we can change that and turn it into a platform again! I think your mail is actually pretty offensive and also misrepresenting GNOME. I will not reply to it. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts extensibility
Hi, On Thu, Oct 6, 2011 at 3:05 PM, Patryk Zawadzki pat...@pld-linux.org wrote: On Thu, Oct 6, 2011 at 7:40 PM, David Zeuthen zeut...@gmail.com wrote: I. Adding support for a provider P, currently means making code-changes to all of the GNOME apps using its services.. because most of the time standard standardized protocols are not in use. For the few cases where it uses a standard protocol (such as XMPP and IMAP/SMTP) we could support pluggable providers. For example, we could, presumably, read plug-in files from some directory so we could list 200 different XMPP chat services or 200 different IMAP servers. That that no-one ever heard about. But would we want the user to see this? The answer is: not in GOA. Can't we just have an option that says Other Jabber/XMPP provider and allows me to enter my JID, the server name, password, port etc.? It would cover most of people's needs even if they need to ask the provider for details (that they have to provide anyway). Most importantly it would mean not using two configuration windows, one of which not showing anything other than Google and the other saying that some accounts could not be configured here. The current state of affairs leads to confusion (I had to explain that to a live person, I failed because I did not have any sensible arguments). Same could probably be done for IMAP/POP3/SMTP. And also for calendar since there's a couple of standardized protocols. FWIW, I don't think it's a bad idea and I actually did something like this early on, see http://people.freedesktop.org/~david/gen-mail-1.png http://people.freedesktop.org/~david/gen-mail-2.png http://people.freedesktop.org/~david/gen-mail-3.png http://people.freedesktop.org/~david/gen-mail-4.png but IIRC the designers had some objections and I ended up running out of time. I'll try to grab the designers again. Would you mind filing a bug about it? Thanks! David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gudev from my grandpa
Hi, On Thu, Aug 25, 2011 at 7:36 AM, Olav Vitters o...@vitters.nl wrote: On Thu, Aug 25, 2011 at 01:34:36PM +0300, Zeeshan Ali (Khattak) wrote: Ah, sorry! My dyslexia kicks-in sometimes. However, thats still pretty old so my question remains. We upgrade if needed. Keeping the requirements low makes it easier to use stuff from your distribution. Is a newer version needed? In this particular case, libgudev version 163 has a bug fix so the library can be used safely in multi-threaded applications. This is the commit in question http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=cbdf255e255adc0f30b40be296fbbf2f3cd2be80 In the future, for gudev, please either track HEAD or rely on the distro to provide a sufficiently new version (ideally the latter) - this business of locking onto old versions is just very bad practice and confusing for everyone and it's pretty annoying to see that bug fixes made almost a year ago isn't being used. Who knows what other kinds of bugs this has caused... 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
Hi, On Fri, May 20, 2011 at 11:21 AM, Johannes Schmid j...@jsschmid.de 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: Online Accounts panel for 3.2
Hey
On Mon, May 16, 2011 at 2:03 PM, Will Thompson
will.thomp...@collabora.co.uk wrote:
Ah! My suggestion was, concretely: rather than
method GetGoogleToken() → s
method GetFacebookToken() → s
method GetOAuthToken() → s
GOA could have either an API which resembles SASL, or…
[...]
Given that GOA already knows the account type etc., it already knows
what kind of mechanisms are appropriate. This would let the Telepathy
GOA plugin avoid needing specific knowledge of each custom XMPP server,
at the cost of GOA itself's providers knowing a little more than just
OAuth2, but not much: X-GOOGLE-TOKEN, for example, is (IIRC) sha1('\0' +
username + '\0' + token), which is to say SASL PLAIN.
If it's really that simple, apps can surely have the switch, no? I
mean, instead of GOA adding API that we might want to remove later? I
mean, for providers this information most likely depends on whether
OAuth 1 or OAuth 2 is needed so the added API would have to go on the
.OAuthBased or .OAuth2Based interface (instead of e.g. the
.GoogleProvider interface). and it would look weird to have a
GetGoogleToken() method on the .OAuthBased interface.
OTOH, if calculating the SASL response involves e.g. private API keys
like it does for calculating the IMAP SASL response, see
http://code.google.com/apis/gmail/oauth/protocol.html
then... then I think GOA _will have_ to contain D-Bus API for doing
this.. because.. we might not want to add API for people to get the
consumer private key because that precludes us from supporting
services where the API key has to be kept a secret. I don't know. Then
again, such TOS are more or less incompatible with free software so
I'm not losing sleep if some downstream can't easily support them. I
don't know. Can of worms.
One thing to be aware of is that GOA might change a
provider from e.g. OAuth 1.x to OAuth 2.x at any point (for example,
Google appears to be switching to OAuth 2.0 but not all services have
been switched over yet) - so we just need to ensure that whatever ends
up interacting with GOA is ready for such a change.
Right. We have GNOME releases as kind of built-in synchronisation
points, I suppose. This might also affect things like libsocialweb more
acutely?
Right, it would affect anything using GOA. But that's just the way it
is, I think.
Cheers,
David
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Accounts panel for 3.2
Hi, On Tue, May 17, 2011 at 9:39 AM, David Zeuthen zeut...@gmail.com wrote: OTOH, if calculating the SASL response involves e.g. private API keys like it does for calculating the IMAP SASL response, see http://code.google.com/apis/gmail/oauth/protocol.html then... then I think GOA _will have_ to contain D-Bus API for doing this.. because.. we might not want to add API for people to get the consumer private key because that precludes us from supporting services where the API key has to be kept a secret. I don't know. Then again, such TOS are more or less incompatible with free software so I'm not losing sleep if some downstream can't easily support them. I don't know. Can of worms. Actually, sorry, I'm smoking crack here - the OAuth Consumer Secret is of course needed for regular OAuth HTTP requests so we _will_ need to expose the OAuth Consumer Secret in our APIs. Note that OAuth 2.0 and bearer tokens just makes a lot of these things a lot easier since it assumes a secure transport instead of allowing providers to use insecure transports. Cheers, David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: language/locale selector [was: Re: Settings downstream would reasonably want to add]
Hey Lennart, On Mon, May 16, 2011 at 1:22 PM, Lennart Poettering mzta...@0pointer.de wrote: I think the right place for tiny mini-daemons like that is probably systemd. I completely agree - it's nice that we finally have a place to do this. And it's nice that you are using D-Bus properties to convey the values since it makes it easy to use with high-level D-Bus bindings with native support for D-Bus properties. However, when you emit the PropertiesChanged signal on the org.fd.DBus.Properties interface, you could pretty please include the value for the property that changed as well [0]? The fact you currently don't (which Bastien found out after I helped him debug his app using your service) means that each instance of each app using your interface manually using your service will have to issue a Property.Get() method invocation. This is both inconvenient [1] and it also causes extra over-head in terms of wakeups etc. from handling these extra messages. It is true that @invalidated_properties has its place (consider huge Blob-like properties), but in this particular case we're talking about tens of bytes extra that is emitted every six months or so that property changes. So I don't think there's any performance impact. Thanks for considering. David [0] : E.g. use @changed_properties instead of @invalidated_properties cf. http://dbus.freedesktop.org/doc/dbus-specification.html#standard-interfaces-properties [1] : though maybe we could do this automatically in GDBusProxy.. but that is against the spirit of using @invalidated_properties instead of @changed_properties so we don't ... it could be turned on by a flag though. It's also slightly racy. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: language/locale selector [was: Re: Settings downstream would reasonably want to add]
Hey, On Tue, May 17, 2011 at 12:49 PM, Lennart Poettering mzta...@0pointer.de wrote: It's mostly a question of laziness on my side. The invalidated_properties stuff I can hook up in matter of seconds. The other props need more work. Excellent, good to hear. Thanks! Cheers, David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: language/locale selector [was: Re: Settings downstream would reasonably want to add]
Hi, On Sun, May 15, 2011 at 5:01 PM, Ross Burton r...@burtonini.com wrote: Let's try that again... On Sunday, 15 May 2011 at 20:10, Lennart Poettering wrote: (Background: I am working on cleaning up all those little services that can change locale/clock/timezone/hostname/... in the context of systemd) In case you were not aware, in MeeGo 1.2 we've added a clock interface to connman. This mainly handles NTP client functionality but can also control (manually or automatically) the system timezone. http://git.kernel.org/?p=network/connman/connman.git;a=blob;f=doc/clock-api.txt If only you'd use the standard org.fd.DBus.Properties interface here then it would be a lot easier to use via e.g. GDBusProxy and other bindings. And it's a lot easier to inspect with tools like gdbus(1) or d-feet(1). Not saying it's impossible to write the code to get the properties and watch for changes - but it's something that _most_ people get wrong or they block the main thread or they end up with proxies where half the properties is from the old owner and the other half is from the new owner. Things like that. (I also see this is using an object exported at / - that's wrong too but it's a lot harder to get this point across to people.) /random_rant_no_need_to_follow_up David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Accounts panel for 3.2
Hi,
On Fri, May 13, 2011 at 7:34 AM, Will Thompson
will.thomp...@collabora.co.uk wrote:
For example, for GMail, you can use the OAuth token when
authenticating the IMAP and SMTP connection cf.
http://code.google.com/apis/gmail/oauth/
This big-switch-statement-in-every-application approach concerns me: it
would be better to essentially delegate the SASL exchange to GOA. Doing
so would minimize the number of components that need to be updated to
support a new custom authentication mechanism for an otherwise standard
protocol. Obviously I'm going to use Telepathy and XMPP for an example
of why :), but I think the same reasoning holds for IMAP, based on that
link above, and other services.
Google Talk is just another XMPP server that happens to support an
X-GOOGLE-TOKEN SASL mechanism. Facebook is just another XMPP server
which supports an X-FACEBOOK-PLATFORM mechanism. Gabble (the XMPP
backend for Telepathy) doesn't implement either mechanism: it just
exposes the SASL challenge over D-Bus. Empathy has a client for that API
that uses gnome-keyring to get the password; on MeeGo Netbook there's a
client that implements X-FACEBOOK-PLATFORM. In a GOA world, we'd ideally
like to avoid the handler having to have a big switch statement for
every supported account type: GOA already has Google-specific code, and
it already knows that this account is a Google account, so it could
implement the X-GOOGLE-TOKEN mechanism in the Google-specific code there.
Then, to support a hypothetical Flickr XMPP/IMAP/c service with
X-PICTURES-OF-CATS authentication, we'd only have to add Flickr code to
GOA; we wouldn't have to touch the authentication code in Evolution or
Telepathy.
(This is one beef I have with Nokia's Signon framework: the Telepathy
bridge for that has to have a big switch statement for each supported
account type, on top of the account type-specific plugins for signond.
It would be nice to not repeat that.)
Right, I thought about that. We basically have a N times M times P problem, e.g.
- N providers with varying APIs
- Google, Yahoo, ...
- M kinds of services we want to support
- Mail, Chat, Calendar, Contacts, Storage,
- P number of libraries/frameworks or apps
- libs: e-d-s, libsocialweb, libfolks, Telepathy
- apps: evolution, thunderbird, empathy, nautilus-send-to
To start with what the user sees, see the mockups here
http://mail.gnome.org/archives/desktop-devel-list/2011-April/msg00107.html
Basically each Switch in that UI correspond to the M kinds of services
- e.g. each configured account has up to M of them. Now, I'm saying
up to M because we obviously don't want to show
[ON ] Chat
for your Google account unless it actually means you can chat in GNOME
with it (e.g. the Shell and Empathy supporting it - which basically
comes down to if Telepathy is supporting it).
Btw, already at this point, it should be clear why all this needs to
happen in the well-defined sandbox that is GNOME: we can't go add
support for providers or kinds of services willy-nilly - it all has to
be coordinated in a way so it all works. For chat, it means
coordinating GOA and Telepathy. For other kinds of services (like Mail
or Calendar), it may be harder - especially if it involves
coordinating the effort with multiple apps (such as both Evolution and
Thunderbird) or multiple libraries.
So my current experiments [1] actually reflect this thinking .. in
fact, right now I'm working on the Mail experience, basically trying
to implement something like these mockups
https://live.gnome.org/GnomeShell/Design/Guidelines/MessageTray/Email
For that, I have code (hundreds, not thousands of LOC) in the Shell
that talks to this interface exported by GOA
http://people.freedesktop.org/~david/goa-20110512/gdbus-org.gnome.OnlineAccounts.Mail.html
http://people.freedesktop.org/~david/goa-20110512/gdbus-org.gnome.OnlineAccounts.Mail.Query.html
It works great, see
http://people.freedesktop.org/~david/mail-notif-1.png
http://people.freedesktop.org/~david/mail-notif-2.png
http://people.freedesktop.org/~david/mail-notif-3.png
I was thinking of adding a method such on the
org.gnome.OnlineAccounts.Mail interface like this
GetAuthenticatedImapConnection (OUT h file_descriptor);
GetAuthenticatedSmtpConnection (OUT h file_descriptor);
that your mail application can use. For Chat, my thinking is that we
could have something similar e.g.
GetAuthenticatedXmppConnection (OUT h file_descriptor);
that Telepathy can use. Does that sounds OK?
Anyway, how we balance where to put implementations is a very hard
question that I'm still thinking about. I'm leaning towards
- For every service type (Mail, Calendar, etc.) should provide a
simple interface that the Shell can use for notification
- One example is the org.g.OA.{Mail,MailQuery} interfaces
- Unless of course there's a good solution there already - for e.g.
Chat we have Telepathy which is awesome so all we provide
Re: no external panels for gnome-control-center [was GNOME Feature Proposal: Backup]
Hi, On Thu, May 12, 2011 at 3:45 PM, Sergey Udaltsov sergey.udalt...@gmail.com wrote: GNOME is a core desktop (desktop building toolkit, if you like) that is used by distributions No, GNOME is not a supermarket. It's not a place where you go to get your technology so you can put it together in your own sandbox. This might be inconvenient for downstreams (including my employer) but it is what it is. The fact that you _can_ (easily) fork GNOME just happens to be a side-effect of the license. It's not the major point of the project. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was GNOME Feature Proposal: Backup]
Hi, On Thu, May 12, 2011 at 4:39 PM, Sergey Udaltsov sergey.udalt...@gmail.com wrote: My whole point was that in the ideal world GNOME could be extensible enough so that no _forking_ would be necessary. Extension modules, not patches. That would be not a side effect of the license but the fundamental feature of the architecture. Do you see the difference? Yes. I also think we tried that with GNOME 2 and failed. I mean, look at GNOME 2's control center - on all distros, it's a royal mess of random crap from either GNOME, the distro or 3rd party app written by a kid in a basement. With GNOME 3.2, we will have a simpler control center (since the extension mechanism is going away) but it will be _awesome_. Sure, the GNOME 3.x control center doesn't do all you need yet but the point really is that we're engaging the current providers of control center items to _work_ with GNOME. In particular, it means working with designers. And in some cases (e.g. boot loader) the solution is sometimes to not have a control center item... but maybe put the feature in the system restart dialog instead. The other bonus thing is that GNOME will _include_ the feature instead of each and every distro doing their own thing. So in the long run everybody wins [1]. Extension- and plug-in systems is often the symptom of a disease. Especially in young evolving software such as e.g. GNOME 3.x. Don't succumb to it. Just say no. David [1] : Except of course if some downstreams do development in their own fucking sandbox.. no, this is not a cheap jab at Canonical.. it includes e.g. Red Hat too. Or SUSE. Trust me when I say that the RH desktop team and the RH team doing the system-config-* tools have fought _a lot_ about these issues. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was GNOME Feature Proposal: Backup]
On Thu, May 12, 2011 at 5:23 PM, Sergey Udaltsov sergey.udalt...@gmail.com wrote: Extension- and plug-in systems is often the symptom of a disease. How would you distinguish...? I don't know. It's typically a highly subjective thing. Mostly it comes down to what most people refer to as good taste vs bad taste. I don't know. [1] : Except of course if some downstreams do development in their own fucking sandbox.. no, this is not a cheap jab at Canonical.. it includes e.g. Red Hat too. Or SUSE. Thank you, that is very interesting and insightful info. The question is - could (or would) GNOME do something to avoid that situation with distros? Not showing 3rd party panels is one path forward. And I think it's the right one. If all distros just patch in their own panels, maybe we need to use a bigger stick to make them work upstream. g-c-c could be for linux what system preferences are for macos or control panel for windows - configuring every aspect of OS except configs of desktop apps (but including system configs, server apps config etc). But that way you end up with useless things like a Java Control Panel or httpd Control Panel [1] and other non-sense that you see on Windows (and OS X for that matter - it's just that people don't install much 3rd party crap there). [1] : for example, system-config-httpd in Fedora is nothing more than an fancy editor for /etc/httpd/conf/httpd.conf - it's a completely inappropriate app because if you know what httpd is, you really don't want to click GUI buttons - you want to edit the config file with vi(1) or whatever your editor of choice is. Same goes for a lot of other distro-specific config tools created because we need a GUI without really thinking whether it was a good idea. /rant Well, if gnome does not want it, let it be so. I am just kindly asking to put together some kind of policy document about all those things. Is that a reasonable and constructive request? Not sure we need to be all lawyerish about it and write policy documents and whatnot - I'd rather people spend time on writing awesome code and doing awesome designs. All in the same sandbox :-) And, FWIW, I'm just expressing my personal opinion about GNOME and nothing I'm saying here is authoritative. It could be that the gnome-control-center maintainers and others have other views about it. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was GNOME Feature Proposal: Backup]
Hi, On Thu, May 12, 2011 at 5:47 PM, Sergey Udaltsov sergey.udalt...@gmail.com wrote: an fancy editor for /etc/httpd/conf/httpd.conf - it's a completely inappropriate app because if you know what httpd is, you really don't want to click GUI buttons - you want to edit the config file with vi(1) or whatever your editor of choice is. Same goes for a lot of other distro-specific config tools created because we need a GUI without really thinking whether it was a good idea. /rant Err... Personally I always thought that the area where IIS was way ahead of httpd is the GUI configuration tools nicely integrated into system configuration GUIs. Didn't IIS actually add a configuration file after strong demands from administrator? I don't know, it's not important. Now, whether a HTTP server needs config UI or not... nothing prevents anyone from writing an app that does that... It just won't be shown in the System Settings, that's all. Which I actually think makes sense. I actually regard a stock HTTP server like Apache (or even an application server such as e.g. Tomcat) more as an application, not an OS component. And I think, these days, you'd maybe want to write the configuration UI for a webserver using HTML5 and JS anyway. I don't know. That said, it could be that some HTTP server configuration could appear in the Sharing panel, see http://live.gnome.org/ThreePointOne/Features/Sharing - for example, to share your public folder via HTTP and exposing a bookmark via mDNS so it shows up in browsers on the LAN that supports this (for example, Safari and Epiphany I think). That would be handy. Either way, I think this is completely orthogonal to the discussion on whether such a panel makes sense. I'm just mentioning this to explain how GNOME should, no wait, MUST, be driven by design. Not some misguided feature-for-feature parity thing or some PHB-directive saying everything needs a GUI. In there lies madness. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was GNOME Feature Proposal: Backup]
Hi, On Thu, May 12, 2011 at 6:34 PM, Luca Ferretti lferr...@gnome.org wrote: Il giorno gio, 12/05/2011 alle 18.14 -0400, David Zeuthen ha scritto: So? Why this should be a failure? Because the premise of System Settings in GNOME 3 is, surprisingly, to change your system settings or personalize the experience. So, are there no system settings or personalizations other then the ones provided by GNOME? 6.x billions of people and only ten (or so) settings panel? We should strive to make this as easy as possible and having 20 panels such as Java Settings or HTTPD Control or even Firewall is something that gets in the way. So if we allowed 3rd party panels, it would be a failure because trusting that people won't write broken panels like the ones mentioned above is, unfortunately, very naive. Wait: first, it's GNOME3, not GNOME2, you can't provide a new panel simply adding a .desktop file with proper keys. You have to develop it using proper API. This is a first barrier for broken stuff. Second: are we a censorship? are we fighting against the ugly? are all non-gnome developers odd and stupid? It seems your starting point is: everybody's wrong, but not GNOME people. I feel it really offensive and counterproductive for GNOME project itself. Speaking of offensive, suggesting that GNOME is a censorship is pretty offensive. Not to mention insulting. I'm not going to have a conversation with you like this. Please keep it real. Thanks, David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was GNOME Feature Proposal: Backup]
Hi, 2011/5/12 Sergey Udaltsov sergey.udalt...@gmail.com: How can Redhat compete with SUSE if both of them use GNOME that defines _final_ user experience? This is just absurd - distros were never supposed to compete with each other (if I had my way, anyway) - just check the Internet where people been cringing about such infighting over 1% user share that the Linux desktop commands. If GNOME is competing against anyone, it's Microsoft Windows, Apple's OS X and maybe a select few others. Maybe you should check up on e.g. Red Hat's or Novell's business model. And compare it with the business model of less successful distro companies. Hint: it's not about how the desktop user experience is defined. Or what set of kernel patches that is being carrier. Or whether the distro bends over and ships illegal kernel modules in the name of competing with other distros. I think the idea that GNOME is the final-final product is unrealistically selfish. You know what I think is selfish? Treating GNOME like it's just a factory spitting out technology, at your bidding, that you can put together as you see fit. And then not giving any credit or contributing your changes back upstream. Think about it. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Accounts panel for 3.2
Hey Matt,
On Thu, Apr 28, 2011 at 2:06 PM, Matthew Barnes mbar...@redhat.com wrote:
On Wed, 2011-04-27 at 09:18 -0400, David Zeuthen wrote:
First, I think this is such an important area for GNOME that we want
to be in control of our own destiny - e.g. I don't think the problem
space is well-enough understood that we want to commit to stable APIs
or sharing code with others. Not yet. Maybe when all this is better
understood we can start moving things to freedesktop.org and sharing
interfaces with e.g. KDE, Qt or whatever. But I really don't think
that we are there yet (we've seen with e.g. org.fd.Notifications what
mess it can be if you standardize early).
I agree, but for the the time being I view GOA integration as an
optional add-on enhancement for Evolution, similar to how we use
NetworkManager.
We have a lot of users that run other desktops and I'd like to keep Evo
fully functional in the absence of an OnlineAccounts service, and thus
avoid any hard dependencies.
Is that inline with what you had intended for this service: as something
for applications to opt into? Thunderbird, for example, could opt in
with their own GOA add-on just as easily as Evolution.
Right - I think it's fine to have GOA as an optional dependency of
Evolution. Realistically, I think most distros are going to build it
with GOA support so it will probably pull in libgoa-1.0.so - but the
dependency on the packages containing goa-daemon(8) could be optional.
Or the app could speak D-Bus directly if it wants.
On dependencies: we are trying hard to move away from libdbus-1 and
libdbus-glib-1 towards GDBus. We also don't want any deps (run-time or
otherwise) on Qt or e.g. cryptsetup or dm-luks. We also really should
be using the platform keyring API (e.g. gnome-keyring) whenever
possible.
How and when will you be using gnome-keyring (or I guess technically the
org.freedesktop.secrets service)? What kind of meta-data schema will
the keyring entries use, so that E-D-S might find and reuse them?
Otherwise, the D-Bus API you proposed sounds pretty easy to wire up to
what we have (or will have), if I'm understanding all this correctly.
I'm happy with what I've seen so far.
The fact that goa-daemon is using gnome-keyring is something I want to
keep as a private implementation detail. The reason is that we're not
just storing passwords - we're storing tokens and exactly what tokens
and how many per account depends on the access-control framework used.
There's also caching (access tokens typically have finite life and
needs to be refreshed) and locking (multiple apps might request a
token at the same time) involved so we just cannot hand out access to
apps like that. And the daemon is also showing notifications if the
user needs to be involved.
Basically, GOA is designed so the app won't need to worry about any of
this - the app can simply get the credentials from GOA and do its
thing. And if the credential doesn't work (suppose the user revoked
access [1]), then the app doesn't need to do much because GOA will
already have notified the user (through a notification and a red error
icon in the control panel) and whenever the user takes action to
rectify the problem, the app will get notified by a D-Bus signal.
The workflow in an app (such as Evo) would be like this
accounts = goa.get_accounts_of_type('mail')
for a in accounts:
if a is OAuthBased:
(oauth_access_token, oauth_access_token_secret) =
a.OAuthBased.GetAccessToken()
elif a is OAuth2Based:
oauth2_access_token = a.OAuthBased2.GetAccessToken()
elif ...
if a is GoogleAccount:
use API from http://code.google.com/apis/gmail/
with one of the credentials you got above
elif a is YahooAccount
use API from http://developer.yahoo.com/mail/
with one of the credentials you got above
elif ...
For example, for GMail, you can use the OAuth token when
authenticating the IMAP and SMTP connection cf.
http://code.google.com/apis/gmail/oauth/
I'm hoping to have something more concrete (a real release!) ready by
the end of this week or next.
Thanks,
David
[1] : see the video I posted here
http://davidz25.blogspot.com/2011/04/gnome-online-accounts.html
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Accounts panel for 3.2
Hi, On Mon, May 2, 2011 at 11:28 AM, Matthew Barnes mbar...@redhat.com wrote: I'm also wondering if we should somehow lock down GOA-based accounts in Evolution to prevent the user from deleting it through Evolution or changing certain essential details like the host name. I guess that's for us to figure out. Is Empathy planning to do something similar? Yup. Note that GOA has a well-defined format (I need to add this information to some man page soon) for defining accounts - basically key-value files in /etc/goa-1.0/accounts.conf.d/*.conf ~/.config/goa-1.0/accounts.conf.d/*.conf ~/.config/goa-1.0/accounts.conf with goa-daemon(8) listening for changes as well. The way I think it should work is that you can only modify/delete accounts defined in in the latter file - the intent is that the accounts.conf.d directories are for system administrators only. We do need an Account:CanModify property that e.g. the control-center should use to make the Delete button insensitive. Do you think this would work with Evo too? Cheers, David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Accounts panel for 3.2
Hey, On Mon, May 2, 2011 at 2:07 PM, Matthew Barnes mbar...@redhat.com wrote: On Mon, 2011-05-02 at 11:37 -0400, David Zeuthen wrote: Yup. Note that GOA has a well-defined format (I need to add this information to some man page soon) for defining accounts - basically key-value files in /etc/goa-1.0/accounts.conf.d/*.conf ~/.config/goa-1.0/accounts.conf.d/*.conf ~/.config/goa-1.0/accounts.conf with goa-daemon(8) listening for changes as well. The way I think it should work is that you can only modify/delete accounts defined in in the latter file - the intent is that the accounts.conf.d directories are for system administrators only. We do need an Account:CanModify property that e.g. the control-center should use to make the Delete button insensitive. Do you think this would work with Evo too? Evo would be creating its own accounts based GOA accounts, using info from GOA's key files to seed our own. I don't see us modifying GOA's key file at all, do you? No, I don't see you modifying the GOA stuff at all. Maybe I wasn't clear when I mentioned syncing accounts. What I meant was we would listen for added and removed events from GOA and then make the equivalent change in -our own- account system. So GOA would be a read-only source for us, confined to some add-on module. So I *think* we're still on the same page, just want to make sure. A CanModify property should be easy to wire up once our own accounts have some kind of lock down capability. Currently they do not, but I'm already rewriting our account system so it's just a new requirement. Right. The way I'd like to think of it, is that the GOA stuff is the authoritative source - the extra account that you are creating is something that should be keyed off the GOA unique id. So if GOA suddenly no longer lists an account with ID xyz, then it should automatically disappear from Evo as well. Cheers, David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Accounts panel for 3.2
Hey, So I had a look and a think about this - First, I think this is such an important area for GNOME that we want to be in control of our own destiny - e.g. I don't think the problem space is well-enough understood that we want to commit to stable APIs or sharing code with others. Not yet. Maybe when all this is better understood we can start moving things to freedesktop.org and sharing interfaces with e.g. KDE, Qt or whatever. But I really don't think that we are there yet (we've seen with e.g. org.fd.Notifications what mess it can be if you standardize early). On dependencies: we are trying hard to move away from libdbus-1 and libdbus-glib-1 towards GDBus. We also don't want any deps (run-time or otherwise) on Qt or e.g. cryptsetup or dm-luks. We also really should be using the platform keyring API (e.g. gnome-keyring) whenever possible. Configuration: I don't think SQLite is at all what we want. Instead just flat key-value configuration files read from e.g. $HOME/.config/goa-1.0/accounts.conf $HOME/.config/goa-1.0/accounts.d/*conf /etc/goa-1.0/accounts.d/*conf is a lot more friendly. That way, since we'd have a stable configuration file format, vendors, sites and users can just drop (or generate) configuration files to reflect their setup [1]. And our daemon should handle file monitoring so things Just Work(tm) when that happens. We might also want to use GSettings here but I'm not sure. We probably want to embed a web browser engine for the Online Accounts panel - e.g. I don't think it's not good enough to rely on the users browser with the way e.g. OAuth2 works -- you really want to intercept the redirect URL and not have to scrape the authorization code out of a window title (as the Google OAuth2 docs humorously suggests) or have the user copy/paste it to the panel. In this case we want to use WebkitGTK+ which has WebKitWebView::navigation-policy-decision-requested signal to solve this. All this could probably be made to work in a platform-independent way (so OtherDesktop can use OtherDesktopWebView) but I'm just not sure I really see the point in that. We want all this in a single project with a single set of coherent docs. E.g. it should be possible to just clone one git repo from git.gnome.org and then you have everything you need. As equally important, docs from said project should be in a single doc area on developer.gnome.org. I don't think we want any foreign plug-in mechanism (e.g. XML files) to describe services. Instead, we should have a set of abstract base classes that e.g. Google, Facebook, Yahoo etc. backends can extend (and that way share code) and have a GIOExtensionPoint for this. We won't (of course) load 3rd party extensions from the get-go though. Maybe later. So as mentioned last week, I was already hacking on something along these lines that works this way. I'll try to get it into a shape where it can be shared Real Soon Now(tm). Thanks, David [1] : e.g. $ cat ~/.config/goa-1.0/accounts.conf EOF [Account some_id] Name=Some Account Type=google EmailAddress=zeut...@gmail.com EOF ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Accounts panel for 3.2
Hi, On Wed, Apr 27, 2011 at 10:07 AM, Ross Burton r...@burtonini.com wrote: On 27 April 2011 14:18, David Zeuthen zeut...@gmail.com wrote: We probably want to embed a web browser engine for the Online Accounts panel - e.g. I don't think it's not good enough to rely on the users browser with the way e.g. OAuth2 works -- you really want to intercept the redirect URL and not have to scrape the authorization code out of a window title (as the Google OAuth2 docs humorously suggests) or have the user copy/paste it to the panel. In this case we want to use WebkitGTK+ which has WebKitWebView::navigation-policy-decision-requested signal to solve this. Some services such as Fire Eagle recommend that you use the default web browser and don't embed a HTML widget on the grounds that the user will then see the URL and other security information that they are used to, and not just random HTML that could well be faked. They then recommend to redirect back to the application by registering a new URL protocol (say, x-myapp-auth) and redirecting there. These rationales seemed really sensible so we tried this in MeeGo and discovered that Fire Eagle is the only service we found who doesn't mandate that the redirect URL is valid, meaning a http: URL. Some even refused to redirect to localhost after the settings app started a private HTTP server on the loopback interface. So yes, I'd say that embedding a HTML engine is fairly important. Being able to support the user's own browser is probably a good idea too though. Yeah, I want to make this possible, on a per-service basis, as well. It might include having the Online Accounts showing something like this Paste the code from your browser here: [] in the Add Account workflow... which is a little annoying but, I guess, OK. (Btw, we could also have something like a https://www.gnome.org/goa-aoauth-redirector web service that could be used as the redirect_url. This web service would then be used to transfer the authorization_code back to the desktop client (the desktop client would register with that web service beforehand and use the state= parameter to identify the callback). But having user credentials flow through gnome.org is really something I want to avoid - it sounds like a disaster in the making.) David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Accounts panel for 3.2
Hey, On Wed, Apr 27, 2011 at 10:52 AM, Alberto Mardegan ma...@users.sourceforge.net wrote: On dependencies: we are trying hard to move away from libdbus-1 and libdbus-glib-1 towards GDBus. As far as libaccounts is concerned, this can be changed easily -- although I don't see a real benefit in moving to a slower implementation... What do you mean by slower implementation? Configuration: I don't think SQLite is at all what we want. Why not? Is it an unwanted dependency, or do you think that using it is overengineering? I just don't think it's good for storing user configuration. Especially not on multi-user or managed- systems where it's useful being able to configure 1000 users by dropping a simple file in /etc. If you want to go for the daemon approach, then yes, key-value files are just fine. But then you'll have asynchronous APIs, which seems much more overhead to me than directly using SQLite. Not necessarily. My implementation is using the upcoming org.freedesktop.DBus.ObjectManager so all the async issues basically go away. See http://people.freedesktop.org/~david/goa-20110427/ for the API. OK, so getting the initial GoaClient object is an async op (you can do it sync which is fine - it's a local RPC call that is guaranteed to return very quickly), but from there it's smooth sailing - you get property changes and so forth for free. I don't think we want any foreign plug-in mechanism (e.g. XML files) to describe services. Instead, we should have a set of abstract base classes that e.g. Google, Facebook, Yahoo etc. backends can extend (and that way share code) and have a GIOExtensionPoint for this. We won't (of course) load 3rd party extensions from the get-go though. Maybe later. But then, how would a certain application get the title and the icon of the GoogleTalk service? Loading a binary plugin? By http://people.freedesktop.org/~david/goa-20110427/gdbus-org.gnome.OnlineAccounts.Account.html#gdbus-property-org-gnome-OnlineAccounts-Account.Name In C, this would be http://people.freedesktop.org/~david/goa-20110427/GoaAccount.html#goa-account-get-name We could easily add support for getting the icon as well. Or if you are dealing with a Facebook account, you'd use the Facebook specific interfaces http://people.freedesktop.org/~david/goa-20110427/gdbus-org.gnome.OnlineAccounts.FacebookAccount.html http://people.freedesktop.org/~david/goa-20110427/GoaFacebookAccount.html to get information. Again, we can add more stuff as needed. So as mentioned last week, I was already hacking on something along these lines that works this way. I'll try to get it into a shape where it can be shared Real Soon Now(tm). See http://davidz25.blogspot.com/2011/04/gnome-online-accounts.html - there's also a video of how the panel. Good to hear, but why not using something that is already there and offers more functionalities than what you propose (with extensions for providers, service and service-type descriptions, a mechanism of specifying default settings, etc.)? Because of the concerns I voiced in the last mail. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Accounts panel for 3.2
Hi, On Wed, Apr 27, 2011 at 12:11 PM, Alberto Mardegan ma...@users.sourceforge.net wrote: On 04/27/2011 07:01 PM, David Zeuthen wrote: So yes, I'd say that embedding a HTML engine is fairly important. Being able to support the user's own browser is probably a good idea too though. Yeah, I want to make this possible, on a per-service basis, as well. Yes, if you have service plugins or configuration files you could specify whether the OAuth callback should be a local webserver or a normal web page, and then have your own browser widget. The code is already arranged this way - but we don't load 3rd party plug-ins. And this is on purpose. Anyway, in this case, it would just be a property on the GoaBackendOAuth2Provider base class http://people.freedesktop.org/~david/goa-20110427/GoaBackendOAuth2Provider.html which the Google and Facebook implementations already use. I will add support for this soon. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Accounts panel for 3.2
Hi, On Wed, Apr 27, 2011 at 1:16 PM, Alberto Mardegan ma...@users.sourceforge.net wrote: Hi David, On 04/27/2011 07:10 PM, David Zeuthen wrote: On Wed, Apr 27, 2011 at 10:52 AM, Alberto Mardegan ma...@users.sourceforge.net wrote: On dependencies: we are trying hard to move away from libdbus-1 and libdbus-glib-1 towards GDBus. As far as libaccounts is concerned, this can be changed easily -- although I don't see a real benefit in moving to a slower implementation... What do you mean by slower implementation? Well, you should know I guess. :-) http://lists.freedesktop.org/archives/dbus/2011-January/013981.html Whether we trust the test is another issue (I didn't try it myself), but anyway I don't see strong reasons for changing an existing piece of code to GDBus (of course, if we were talking about newly written code, things would be different). Oh, that old thread. Well, I'll just repeat what I've always been saying: if a factor of 4 going to kill you, then you are already using D-Bus incorrectly. Either way, as I said in bug 634471 (which is where discussion of GDBus performance should take place), I'm not opposed to optimizing GDBus - I just want someone to actually benchmark things sensible instead of this completely baseless GDBus is slow non-sense, sorry. And, btw, if you are already using libdbus-1 and/or libdbus-glib-1 you should worry about threading instead of performance. Configuration: I don't think SQLite is at all what we want. Why not? Is it an unwanted dependency, or do you think that using it is overengineering? I just don't think it's good for storing user configuration. Especially not on multi-user or managed- systems where it's useful being able to configure 1000 users by dropping a simple file in /etc. I'm not sure I'm following you... If by 1000 users you mean 1000 accounts for one user, then even in libaccounts-glib case that's just one file. If you are talking about real 1000 users, each one having some accounts, libaccounts would indeed require you to have 1000 different files -- but I don't see how this could be different for GOA: would you store the accounts of 1000 users in a single file? In any case, I fail to see the use case for it. I'm talking about having 1000 Unix users on a big box (or each on separate boxes). For example, if I'm a sysadmin for the City of Largo, then it would be nice if I could just drop a file so that the City Events calendar account is included for each account. This is nothing new - it's what we've been doing with GConf defaults etc. forever. Not necessarily. My implementation is using the upcoming org.freedesktop.DBus.ObjectManager so all the async issues basically go away. See http://people.freedesktop.org/~david/goa-20110427/ for the API. OK, so getting the initial GoaClient object is an async op (you can do it sync which is fine - it's a local RPC call that is guaranteed to return very quickly), but from there it's smooth sailing - you get property changes and so forth for free. Neat. I would also suggest you to do the same thing when changing the accounts: that is, instead of having an async/sync version of every _set method, just have a synchronous one which sets the value locally, and a per-account sync method (or even on the GoaClient). I don't think any client except the configuration UI is supposed to do any set calls. And, btw, setting a D-Bus property from a client app has no error checking (same way g_object_set() has no error checking) because the daemon-side is designed to not have writable properties. So the programmer does not have to worry about the async aspect. Sure. But it beats me that we are making a D-Bus call for something that could just be obtained directly. Since this information is static, why not just read it directly from somewhere in the file system? I don't think you understand how it works - the _only_ D-Bus call that is made is the initial GetManagedObjects() D-Bus call. Everything else is cached in each client and updated in response to PropertiesChanged signals. That's just how org.freedesktop.DBus.ObjectManager works... So as mentioned last week, I was already hacking on something along these lines that works this way. I'll try to get it into a shape where it can be shared Real Soon Now(tm). See http://davidz25.blogspot.com/2011/04/gnome-online-accounts.html - there's also a video of how the panel. Functionality wise -- cool! :-) Security wise not so much, Excuse me? Why exactly is this not secure? even though I understand that security is not the focus of the GNOME desktop. That's non-sense. Security is just as important in GNOME as in any other sensibly designed environment. I see a few issues with your implementation, which IMHO largely surpass the flaws you noticed in libaccounts-glib dependencies: - it's not yet ready :-) It's fine, we're doing time-based releases. We also specifically don't want to commit to any stable API
Re: Online Accounts panel for 3.2
On Wed, Apr 27, 2011 at 3:15 PM, Alberto Mardegan ma...@users.sourceforge.net wrote: I don't think that switching to GDbus would kill performances; I'm just arguing that I don't see a good reason to change some existing code to use it, since it's not better than libdbus (though it might be better from a maintainability POV). The reason is that if you are writing a library intended to be used by GNOME apps and you are using libdbus each app using it suddenly has two connections to the session bus daemon instead of just one (one from libdbus, one from GDBus). This is not very good. The GDBus API is also a lot nicer if you are used to GLib-style APIs ... then again I'm a bit biased since I wrote GDBus. But, then again, the original D-Bus author, Havoc, came up with a lot of suggestions for the GDBus APIs. See the gtk-devel-list archives for details. And, btw, if you are already using libdbus-1 and/or libdbus-glib-1 you should worry about threading instead of performance. They are thread-safe, aren't they? Uhm. No. And I know this because I initially based GDBus on top of libdbus-1 but it failed in pretty spectacular ways once I added multi-threaded test cases. I don't think any client except the configuration UI is supposed to do any set calls. It's not necessary, but it might be very convenient for applications to store some account-specific settings there. For instance, an instant messaging application might want to store the default requested presence for the account (that is, having a property DefaultPresence which would be set to online, busy, etc.). Though indeed this data might be stored somewhere else and bound to the account via the unique account ID. Indeed. At this point, IMHO, it would be better if in order to get the Google icon (and other settings) one would read a static file, whose path is uniquely identified by the provider name, and get the information from there. While, if I understand you correctly, you would pass this information along with the accounts data, in the first D-Bus call. OK, this probably is not a performance problem in the desktop, but still it's suboptimal, at least memory-wise. No-one says that we are passing raw image data over D-Bus as properties - we can do clever stuff like passing a serialized GIcon instance and have something like a GoaHTTPIcon type in the client-library. That way we'll just pass an URI in that serialized GIcon data. See http://git.gnome.org/browse/gvfs/tree/client/gvfsiconloadable.c?h=gnome-3-0 for similar tricks done in GVfs to load thumbnails directly from the device. We could also just decide to not have any icons/images be properties - instead, we can just provide a D-Bus method to get the icon/image. Then the implementation can read it directly from the network if wanted. That's non-sense. Security is just as important in GNOME as in any other sensibly designed environment. Sorry, I probably should have clarified better what kind of security I'm talking about: I'm not referring to network security or even to local security threats coming from other local users. It's about trusting the applications that the user installs, and having different access rights. With this approach, we don't let applications specify their own application token, and request different authorizations to the account's data (for the OAuth case). I beg pardon -- having the word security associated with a certain context for 8 hours per day, I probably abused it here. But this is indeed the kind of security I had in mind, and I think you'll convene that it's not something GNOME is much concerned about. :-) For the record, I think it's wrong to say that GNOME isn't concerned about it and it's something at least I take offense at. And I'm honestly not sure why you think GOA is that much different from your stuff. For OAuth2 based services, which is all we support right now, applications can only get the so-called Access Token from goa-daemon, cf. http://people.freedesktop.org/~david/goa-20110427/gdbus-org.gnome.OnlineAccounts.AccessTokenBased.html#gdbus-method-org-gnome-OnlineAccounts-AccessTokenBased.GetAccessToken You know... if we wanted, we could be more discerning and put up dialogs like GWibber is requesting access to your Twitter account [Deny] [Allow] much like we are already doing for system services via polkit cf. http://davidz25.blogspot.com/2011/02/gnome-3-authorization.html but since the desktop is already one security context already, this is more or less just pointless snakeoil. It would look cute though :-) FWIW, I agree such dialogs make sense in the case where you have a proper security architecture, like on Android, and each app is truly its own security context and can't ptrace(2) each other and so on. Last time I checked, this wasn't the case with Meego, maybe it's different now. I don't know. - it doesn't have the concept of different services on the same account (in this respect, I think
Online Accounts panel for 3.2
Hey, One of the things I'm looking at doing for 3.2 is the Web Accounts panel: http://live.gnome.org/ThreePointOne/Features/Sharing http://live.gnome.org/Design/SystemSettings/Profile I sat down last week with one of the designers, Jon McCann, and we came up with what we both think is a really nice user experience. It is described in [1] for now - will move to the wiki soon. Implementation-wise, I can see this as a very minimal daemon / library that sits below libsocialweb, Telepathy, e-d-s and other APIs (e.g. these libraries/frameworks would use this new framework) that is dealing data online accounts. This daemon / library would a. have a notion of source types - email source - calendar source - chat source - photos source - contacts source - ... b. have a notion of providers that can be added removed by the end user - Google (for accounts at google.com and Apps For Your Domain) - Yahoo/Flickr - Exchange - Facebook - ... c. provide a concrete list of providers and what sources the instance of the provider supports. For example, for my setup, I would have the following - zeut...@gmail.com (an instance of the Google data provider) - Mail (email source) - Contacts (contacts source) - Calendar (calendar source) - Chat (chat source) - da...@fubar.dk (an instance of the Google data provider) - (works because fubar.dk is using Google Apps For Your Domain) - Mail (email source) - dzeut...@yahoo.com (an instance of the Yahoo! data provider) - Flickr! (photos source) - (I specifically unchecked mail here because I don't want the spam that is in that email account that I never use) - davidz25 (an instance of the Facebook data provider) - Messages (email source) - Events (calendar source) The information in c. would map exactly to what the Web Accounts UI would display: +--+ | All Settings | +--+ | +---+ Google Account| | | [Go] zeut...@gmail.com|| | | [Go] da...@fubar.dk (!) | Username: david | | | [Y!] dzeut...@yahoo.com | Domain: fubar.dk_ | | | [Fb] davidz25 || | | | Use this account for: | | | || | | | [ON ] Mail | | | | [ OFF] Chat | | | | [ OFF] Contacts | | | | [ OFF] Calendar | | | || | +---+ (!) Authorization expired. | | | [+] [-] | Please login again.| | +---+[Login] | +--+ This screenshot shows an example where the da...@fubar.dk account needs attention (suppose that the password has been changed from another system). In this case, I think the desktop would show the user a notification saying The account da...@fubar.dk needs your attention and upon clicking on it, the user is taking to the control-center pane above. This daemon/library thing, let's call it GOA (Gnome Online Accounts), would _not_ be a mechanism to access any of these services. But it would provide e.g. libsocialweb, telepathy, e-d-s and so on with either the username/password combo or the OAuth token, whatever is appropriate. I would imagine Telepathy/Empathy to use GOA to get the Chat accounts that is configured in GOA (in the above example, it would be Google Talk from zeut...@gmail.com and Facebook Chat for davidz25). I would use an Empathy specific preferences window (not appearing in gnome-control-center I think) to add e.g. my ICQ account. There are of course security / implementation considerations (password/auth token hygiene, should we treat the desktop like it's not a single security context when it really is?) here - all of that comes next. Technically, I'm proposing that we add a GOA module with - a daemon, goad, that implements the org.gnome.OnlineAccounts interface on a well-known object /org/gnome/OnlineAccounts and owns the well-known name org.gnome.OnlineAccounts (all this is on the session bus). Additionally, this daemon would notify the user if attention is needed (e.g. reauth) using org.freedesktop.Notificatins / libnotify. - a library, libgoa-1.0, that is used to speak to goad (but an app can also just use the D-Bus interface if it wants to). This library is what
Re: Online Accounts panel for 3.2
Hi, On Tue, Apr 19, 2011 at 9:28 AM, Bastien Nocera had...@hadess.net wrote: On Tue, 2011-04-19 at 09:08 -0400, David Zeuthen wrote: snip This daemon/library thing, let's call it GOA (Gnome Online Accounts), would _not_ be a mechanism to access any of these services. But it would provide e.g. libsocialweb, telepathy, e-d-s and so on with either the username/password combo or the OAuth token, whatever is appropriate. The hard part here is handling application-authorisation. For example, for Flickr, it's not enough to have a login/password combo, you also need to allow the framework/application access to the account. You'll also see that both libsocialweb and bisho (the config panel for libsocialweb) have quite a lot of that code, including oauth helpers. It would certainly make sense to split it out of libsocialweb in this case. Yup, I most of that out of my initial description to keep it short (I tried to allude that both authorization (authorize app to use flickr) and authentication (proving to flickr who you are) might need a web browser in the footnote) - would definitely not want to rewrite all that code if it's already written. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Accounts panel for 3.2
On Tue, Apr 19, 2011 at 10:23 AM, David Zeuthen zeut...@gmail.com wrote: Yup, I most of that out of my initial description to keep it short Sorry, I obviously haven't had enough coffee yet - I meant to say that I left authorization and authentication details out of my initial description to keep it short. (I tried to allude that both authorization (authorize app to use flickr) and authentication (proving to flickr who you are) might need a web browser in the footnote) - would definitely not want to rewrite all that code if it's already written. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Accounts panel for 3.2
On Tue, Apr 19, 2011 at 9:57 AM, Milan Bouchet-Valat nalimi...@club.fr wrote: Le mardi 19 avril 2011 à 09:08 -0400, David Zeuthen a écrit : - a daemon, goad, that implements the org.gnome.OnlineAccounts interface on a well-known object /org/gnome/OnlineAccounts and owns the well-known name org.gnome.OnlineAccounts (all this is on the session bus). Additionally, this daemon would notify the user if attention is needed (e.g. reauth) using org.freedesktop.Notificatins / libnotify. Do you really need a daemon? Sounds like everything could be handled by applications that use these accounts via the library. Is there a point in connecting to these accounts if no app is using them? If not, then notifications can be emitted by the app when it tries to connect and finds the password has changed (which would be done automatically by libgoa). And the library would get information about accounts from GSettings and gnome-keyring, without the need for any daemon. It's not unimaginable that some online service might want to use some 3rd party library to do its thing. It's also just a lot simpler to serialize writes etc. if you know that only one process is going to touch the data at any one time. Thanks, David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Accounts panel for 3.2
Hey Alberto, Thanks for your response! On Tue, Apr 19, 2011 at 10:12 AM, Alberto Mardegan ma...@users.sourceforge.net wrote: Hi David, On 04/19/2011 04:08 PM, David Zeuthen wrote: Hey, One of the things I'm looking at doing for 3.2 is the Web Accounts panel: http://live.gnome.org/ThreePointOne/Features/Sharing See the Current status section in that page. We already have all of this (and more) in MeeGo, and I'm willing to support any efforts in bringing this to Gnome. I did briefly look at http://gitorious.org/accounts-sso/accounts-glib but quickly got lost as that appears to be just the client-side GLib glue. And some of the other stuff looked pretty specific to Meego. There are of course security / implementation considerations (password/auth token hygiene, should we treat the desktop like it's not a single security context when it really is?) here - all of that comes next. We addressed all security concerns already; feel free to ask in case you have some doubts. Oh, it's not so much that I had any unresolved concerns - I was just pointing out that I was aware that I knew that I have to be careful there. I'm sure that especially for the SSO part there'll be need for work in order to adapt it to the desktop; but it will still be far quicker than rewriting everything. The accounts part should be already well working on the desktop. Can you give a short overview of exactly what components that you've written that GNOME would use (including their dependencies and whether it's a per-session daemon, per-system daemon or shared library), what GNOME would need to write itself and how it would fit together with the UX that I've described? I mean, obviously accounts-glib would be an external dep and obviously we'd write our own GNOME Control Center panel ... but what else? I'm asking mostly to figure out what additional dependencies this would add to GNOME if we were to use it! Thanks, David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Control Center items (Was Re: Online Accounts panel for 3.2)
Hi, On Tue, Apr 19, 2011 at 10:52 AM, Frederic Peters fpet...@gnome.org wrote: David Zeuthen wrote: I would imagine Telepathy/Empathy to use GOA to get the Chat accounts that is configured in GOA (in the above example, it would be Google Talk from zeut...@gmail.com and Facebook Chat for davidz25). I would use an Empathy specific preferences window (not appearing in gnome-control-center I think) to add e.g. my ICQ account. Could you elaborate on this, e.g. why would ICQ and other types of online accounts be deported to a specific preferences window? I was mostly just thinking out loud - and that thought came out because it would seem weird to both Online Accounts and a Messaging and VoIP Accounts items in the control center (that, and we have limited space there). I guess my view is that mainstream/branded accounts (such as Google, Facebook etc.) would be handled by the Online Accounts panel while something as baroque as ICQ (it was once big but isn't really anymore) would be handled by app-specific preference windows. Or maybe Online Accounts is used to configure not only something like GOA (e.g. branded accounts) but also Telepathy. I don't know. I'm not the best person to make that call - ask the GNOME designers? This is somehow related to the Contacts thread, where it is said we could replace the empathy contact list with the shell; in this scheme there's no place any longer for that specific preferences window, and it makes sense (to me) to have it in the online accounts panel, along others. Sure. FWIW, I think we probably need some high-level design input that takes all these currently moving pieces and proposals into account. Again, I defer to the designers here. (Sorry if this sounds like a cop out. It's not. I agree this is an important thing.) Thanks, David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Control Center items (Was Re: Online Accounts panel for 3.2)
Hi, On Tue, Apr 19, 2011 at 11:24 AM, Frederic Peters fpet...@gnome.org wrote: I am also of the opinion we want a single panel; but I think the design of the online accounts panel should allow the accounts that are currently in the messaging and voip accounts panel I agree. ; nothing really new here, I had that old mockup in mind: http://gitorious.org/gnome-design/gnome-design/blobs/master/mockups/control%20center/web-services/web-services-2.png Yeah, I looked at this too.. and it's somewhat what I had in mind - the only difference is that I think we need to support multiple instances (e.g. multiple Google accounts - I personally have both a gmail.com account and also a google-hosted fubar.dk account). While this might be a 5% thing (I think it's slightly higher actually), enough of us hackers use such a feature so not supporting it means a lot of people won't be eating the dogfood. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: SoC idea: desktop file cache
Hey Colin, On Thu, Mar 24, 2011 at 11:22 PM, Colin Walters walt...@verbum.org wrote: The next question is how does the cache get rebuilt? I think we basically need a system service with an inotify (GFileMonitor) watch on all those directories, and it takes care of rebuilding it. Sounds good, but we really want a session-service [0] instead of a system-service - otherwise it won't work with apps installed in $HOME/.local or whatever $XDG_CONFIG_DIRS points to. With this, could also implement this as a gnome-settings-daemon plug-in if you don't want the overhead of another process. And you completely bypass the nasty (and often overlooked) implications of dealing with two security contexts instead of just one. And you also bypass other nasty problems like $HOME on NFS or automount issues if you decide to fix this flaw later by having the system daemon look in the users home... Btw, if this service runs in the session, it can also be smart about e.g. synthesizing desktop files for glick-style [1] applications previously seen or downloaded or living in ~/Applications or ~/Downloads or something. Of course someone needs to come up with a design for how runtime-less bundles should work but, at least, let's not make it impossible from the get-go by implementing caching at the system-level. (On a machine with a one or two sessions at a time, the session-instead-of-system approach has approximately the same performance characteristics as the system-service approach. On machines with many many sessions (Largo, FL terminal servers for example) you might want to also have a system-wide cache that each session can use. Could be it doesn't matter doing such a (premature) optimization though.) David [0] : you actually really want a service that is per (user, machine) instead of per-session... this is easiest implemented by using the D-Bus name org.service.machine-id on the session bus and using storage in $HOME/.local/service/machine-machine-id for the cache [1] : http://blogs.gnome.org/alexl/2007/08/07/experiments-with-runtime-less-app-bundles/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
Hi, On Thu, Oct 7, 2010 at 7:38 AM, Vincent Untz vu...@gnome.org wrote: Candidates for this set include: ConsoleKit, NetworkManager, Xorg, avahi, bluez, cairo, dbus, geoclue, gudev, libxml, pulseaudio, udisks, upower. This should include polkit since a) udisks and other services will not work without it; and b) other parts of our stack (such as dconf) really wants to rely on it too. Thanks, David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module decisions for 3.0
Hey, On Tue, Jun 1, 2010 at 8:48 PM, Joe Marcus Clarke mar...@freebsd.org wrote: On Tue, 2010-06-01 at 20:20 -0400, Matthias Clasen wrote: On Tue, Jun 1, 2010 at 7:38 PM, Vincent Untz vu...@gnome.org wrote: Hi, + Since we don't have HAL anymore, we need to clearly document what code needs to be ported to various platforms. See the wiki page: http://live.gnome.org/action/diff/TwoPointThirtyone/PortabilityMatrix Just to emphasize this point: it is a wiki page, and we would appreciate contributions to this table, in particular from people who might have first-hand experience in getting GNOME built on non-linux systems. It's good you started this because I was going to comment. The state of things on FreeBSD is as follows: GIO : volume monitoring : works because it uses hal GIO also works even if you don't have HAL because GIO ships with a GUnixVolumeMonitor that works on most Unices even the really obscure ones. Btw, you could also write a GVolumeMonitor implementation that uses FreeBSD specific APIs to enumerate drives, volumes and mounts. g-d-u : does not work as it requires udev Actually, this should be does not work as it requires udisks. The gdu codebase is very careful about not using Linux specific API and even not assuming the udisks daemon is running on the same host - this is why e.g. management of remote hosts http://people.freedesktop.org/~david/gdu-multiple-servers.png just works. IOW, if you have something implementing the udisks API, then gdu and palimpsest will just work. udisks : does not work as it requires udev Actually udisks is designed in a way so it isn't dependent on Linux and so it can be ported to, say, FreeBSD or Solaris. Honestly, it's this way mostly because Linux itself is a very fluid and moving target Anyway, the docs clearly shows this http://hal.freedesktop.org/docs/udisks/ e.g. Linux specific features are clearly marked as such; IOW there's no attempts to abstract what, say, RAID means and then hope that the Linux implementation (using MD RAID) and the FreeBSD implementation (using Vinum) agrees and both fit a common API. Because I don't think that's ever going to work (the best we can hope for is that both OS'es have a notion of block devices). The udisks codebase however isn't currently set up so it's easy to port the udisks codebase to, say, FreeBSD. But I'm planning to at least make that easier, I'm already busy porting it to use GDBus and a big part of that work is cleaning up the separation between the core service and kernel-OS-specific code. The big problem is clearly udev. Last I looked, it was very Linux-centric (i.e. a very thin wrapper on sysfs which FreeBSD does not have). The reason upower came to be on FreeBSD was that someone abstracted the backends, and made it easy to plug in new ones. Say what you will about hal, it had a spec that made it relatively easy to port from platform to platform with some amount of consistency. In FreeBSD we have a device tree which provides a hierarchy of device nodes, but doesn't give too many details about each device. For that, we have to dig a bit deeper (often times requiring root access). For hal, that wasn't a big deal. We could separate privileges, and things worked. I guess udev is started as root by dbus, so that shouldn't be a big deal. What is a big deal is deciding what device nodes to report and what properties of those nodes to advertise. If there was an abstracted backend API for udev, and a list of common subsystems/devices/properties required, I think it would be possible to integrate the work done in hal. Having backends for udev just doesn't make sense because udev (or sysfs) itself isn't a spec or an abstraction. It's the raw Linux device management API - in a very real sense you are dealing with internal kernel data structures when you peek and poke around in sysfs either directly or indirectly via libudev / libgudev1. So it might be easier just to run Linux instead of trying to emulate it David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module decisions for 3.0
Hey, On Wed, Jun 2, 2010 at 2:23 PM, Richard Hughes hughsi...@gmail.com wrote: On 2 June 2010 17:37, David Zeuthen zeut...@gmail.com wrote: The udisks codebase however isn't currently set up so it's easy to port the udisks codebase to, say, FreeBSD. But I'm planning to at least make that easier, I'm already busy porting it to use GDBus and a big part of that work is cleaning up the separation between the core service and kernel-OS-specific code. The time between me adding the required separation and Makefile glue and the FreeBSD UPower backend getting merged was a matter of weeks. I think it's a classic case of taking the time for the first step and then asking people to fill in the blanks. While there's some truth to that, storage is generally much than system-wide power management - for example, non-Linux udisks backends will have to supply filesystem and partition table routines themselves. And getting it wrong can lead to nasty data corruption disasters etc etc. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.30 and udisks (the module formerly known as DeviceKit-disk)
On Wed, 2010-01-20 at 18:33 -0500, Matthias Clasen wrote: David, any chance to bless a git snapshot as udisks-0.99 so that we have something to keep the processes greased until 1.0.0 ? OK, I'll do a RC1 next week. Thanks, David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.30 and udisks (the module formerly known as DeviceKit-disk)
On Wed, 2010-01-20 at 21:41 +0100, Luca Ferretti wrote: I was rebuilding from scratch my jhbuild sandbox, when gnome-disk-utilities failed due to missing udisks pkg-config file. I tried to search for a released udisks package, but the only one I found is a git snapshot here[1]. So, the following unavoidable questions: * when will be available a stable udisks release? * we'll automatically switch to udisks as external dependence? (I suppose yes) * how many modules currently depends on PolicyKit-disks? (just g-d-u, if I'm right) * what about PolicyKit-power? Cheers, Luca As announced elsewhere, udisks is simply DeviceKit-disks with a name change. FYI, there will be a udisks 1.0.0 release in time for gnome-disk-utility 2.30 - until then, people can use git master or recent distros like Rawhide or whatever. Also, GVfs master still works with gnome-disk-utility 2.28 if you don't want any of the new stuff yet. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On Thu, 2009-10-29 at 22:25 +0100, Luca Ferretti wrote: But in previous GNOME release we accepted stuff like PolicyKit or DeviceKit or PulseAudio while not yet officially released or widely adopted. And those stuff was needed to be installed under /usr in order to properly work. I believe all of these things are (optional) dependencies, not anything part of the GNOME desktop proper. Except for maybe PulseAudio. Solaris, for example, don't use any of this stuff. Tracker, instead, can be simply tested in a JHbuild sandbox. So this doesn't seem to me a reason to drop its inclusion. I'm with Zeeshan on this - what's the harm of delaying the inclusion of Tracker until it has actually proven itself to be useful for Linux Desktop uses? (In my view, Maemo isn't a typical Linux Desktop) Not to sound like an asshole or anything but, I mean, didn't distros try including Tracker by default in previous releases? AFAIR, it didn't really work well. So if GNOME included Tracker in the next release and core parts of GNOME started depending on it in a way that couldn't be turned off... then distros would be in a lot of trouble if Tracker didn't work well. This would probably end up reflecting badly on the GNOME project. Instead, I'd be a lot more thrilled if the Tracker developers would suggest Tracker as an optional dependency (just like e.g. polkit is.. or at least used to be) - e.g. apps using Tracker would have need a --disable-tracker or --enable-tracker configure option. This way we can start integrating Tracker into GNOME without causing the ride to be too bumpy. Thanks, David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On Thu, 2009-10-29 at 22:49 +, Martyn Russell wrote: I believe all of these things are (optional) dependencies, not anything part of the GNOME desktop proper. Except for maybe PulseAudio. Solaris, for example, don't use any of this stuff. That's not true, we have a few Solaris people sending us patches from time to time. I think you misunderstood what I said. I wasn't talking about Tracker. And it's good that the Solaris people are sending you patches. The point, really, is that Luca was incorrect in stating that we (GNOME) unconditionally adopts dependencies that are not widely deployed or fully baked. This was true (and in a sense, still is for some of these components) for polkit, devkit-disks/gnome-disk-utility, Pulseaudio, PackageKit and the list goes on. Why do you think it should it be any different for Tracker? I'm with Zeeshan on this - what's the harm of delaying the inclusion of Tracker until it has actually proven itself to be useful for Linux Desktop uses? (In my view, Maemo isn't a typical Linux Desktop) Maemo is a target platform being used by real people just like the desktop is Of course it is, no one is disputing that. so I don't agree with that argument. Here's the point: Surely, Maemo, or, rather, Nokia (who develops the bulk of Maemo) went through the motions of working out why Tracker is useful and, you know, actually, patched their set of apps to use it. Including spending a lot of money making all this happen. All I'm saying is that we need to do the same in GNOME. This is double-plus true because GNOME has a much more diverse set of downstreams. In other words, there are many products (distros if you like) that incorporate GNOME. Consequently, because GNOME is a lot of things to a lot of people it's much *harder* to figure out how to use and deploy Tracker in a meaningful way. I think the recent threads about Tracker and GNOME really shows this. Anyway, I'm really not so sure why it's so important for you guys to be in the GNOME Desktop right away. Again, I'd much rather see Tracker as a blessed optional dependency (ideally following the GNOME release schedules) while you work with applications authors so they can use Tracker to deliver great value and all that good stuff. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On Thu, 2009-10-29 at 19:38 -0400, Jamie McCracken wrote: this is all hypothetical. What matters is that people actually try it out then make judgements based on whether the current tracker gives a good experience. If people dont do this then the same arguments will be made whenever tracker is proposed again regardless of how good or bad it is Sure. This means you need to lobby the distributions to ensure that Tracker is installed by default. That's what a lot of people are saying here - you need to make sure people feel all warm and fuzzy before you can make them accept a non-optional dependency. The problem is that to leverage the full power of tracker, you need much deeper integration and its not practical to make it optional in those cases This is a very general and broad statement concerning the key element in this discussion. I think it would help your case if you expanded on why this is so and what power would be unleashed. The way I see it is if Gnome wants to be in a position to challenge OS/X and Windows 7 then it needs to make bold decisions. Playing it safe means it will stagnate and Gnome will miss out on all the cool technology. This is kinda hyperbole - not really useful. But, hey, did you know that monitor hotplug in GNOME almost works as well as in Windows 95 now? - That is, if your video driver works with your hardware ;-) (With apologies to the X hackers. The point here, really, is that we have the work cut out for us. Indexing/metadata is important but, uh, there's so much other work that needs to be done too.) David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
gnome-disk-utility branched for 2.28
Hey, This is to let you know that gnome-disk-utility has branched for 2.28, the branch name is gnome-2-28. New development happens on master. Thanks, David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tracker, Zeitgeist, Couchdb...where is the problem ?
On Tue, 2009-08-18 at 16:48 -0400, Matthias Clasen wrote: I think this recent discussion about tracker as a gnome module is somewhat backwards. I don't think it is leading us anywhere to talk about ontologies and rdf and events and timelines and metadata stores and kernel apis before we answer the first question: What is the user problem that we are solving here ? Can that be described in a paragraph ? And if it can, is it something that a 'regular' user would recognize as a problem he has on his computer ? Once we have the problem scoped out, we need to look at the user experience we want to aim for in solving it. Will it be a single search-for-everything dialog ? A query language ? Tagging everywhere ? Excellent suggestion, thanks for bringing some order to this thread Matthias. But kinda sad to see people reply to this with technology evaluations - I mean, COME ON PEOPLE, the point here is to IGNORE technology until we've figure out 1. what problems we want to solve for the user 2. the user experience So, everyone, please refrain from even thinking about mentioning specific projects like tracker, couchdb, zeitgeist, nepomuk, whatever etc. in this thread. Thanks. After that, it might be possible to evaluate whether tracker, zeitgeist, couchdb or something else can be part of the implementation... Suggest to do this in a new thread. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME and non-linux platforms (release team please stand up)
On Tue, 2009-07-28 at 12:10 -0500, Brian Cameron wrote: I have pinged the Sun team working on DeviceKit and suggested they be better about communication with upstream by sending some status to the devkit-devel mailing list. Thanks. Also, Solaris has a security rule that requires that users not be asked to enter passwords for gaining authorization unless they are in the trusted path. To my understanding, PolicyKit does not address this issue today, perhaps because most Linux distros are not as strict about this requirement. This technical issue could be overcome, for example, by switching to a separate VT in the trusted path to display the dialog. Yes, it is entirely possible to easily make PolicyKit use an Authentication Agent that runs outside the session. If you wanted you could even make the authentication agent communicate with a separate device (for example a separate device connected via USB with small display / big flashy button the user can press to authenticate the request) or a mobile phone display (using BT for proximity)... or whatever... e.g. the APIs are in place for such things. And, sure, for home/consumer usage just having both the screensaver unlock dialog, the PolicyKit authentication dialogs and other stuff (such as GMountOperation interaction [1]) running in a trusted sandbox (e.g. separate Xserver/VT) is probably what we want. That way, nothing running in the user session can ever snoop on passwords. Of course this requires a lot of bug fixes in the X.org stack (it is essentially fast user switching), we need a system compositor (like wayland), ConsoleKit changes and so on... so blue sky for now. Btw, I wonder how you implement screen locking (e.g. screen saver) / connecting to network shares (e.g. gvfs) / ssh (via the terminal) if you don't want people to enter passwords... seems like a weird backwards requirement to only require it for gaining authorizations and not for something like unlocking the screen. [1] : See http://mail.gnome.org/archives/gtk-devel-list/2007-December/msg00149.html http://mail.gnome.org/archives/gtk-devel-list/2007-December/msg00169.html There has been some concern expressed about using PolicyKit with an RBAC backend. If Solaris ships configuration files for both RBAC and PolicyKit, then users will likely need to understand and configure both systems to properly configure their setup. There is a desire to avoid adding unnecessary complexity. Perhaps a GUI that hides this complexity from the user could help to address this concern. The only thing you need is to figure out whether an mechanism-defined action (as defined in the .policy file shipping with the mechanism) is allowed or not. So you would just have a small white-list for known applications _if_ you don't want to trust the defaults provided by the mechanism vendor. I think the central problem here has to do with expectations and _who_ you are designing the OS for. Now, PolicyKit allows the mechanism vendor to ship defaults - we need this because in modern desktop systems intended for _consumers_ you (as the OS vendor) have zero control of what is installed by default. Contrast this with the typical mind-set where security/authorization framework designers happily assume they are in full control of what is on the box and provide little or no way for 3rd party apps to participate. It just doesn't work in a modern desktop operating system. Regarding RBAC, it has been a NIST standard since 1992. Sun is just one company that implements RBAC, it is not a Sun technology. The NIST stuff, last time I checked, is more like a list of abstract requirements that can apply to a ton of different systems (including database systems where it is mostly used). Calling RBAC a standard is a stretch, I mean, there's no well-defined API, file formats or anything. Again, PolicyKit is just an _interface_. You can implement almost any kind of access control (both DAC and MAC) since PolicyKit provides a wealth of information about what is going on and the actual decision making happens in a separate trusted process. The default authority implementation in PolicyKit (dubbed the Local Authority) basically implements most of the useful bits of RBAC (as per the NIST requirements). Other PolicyKit authority implementations may implement other things; for example the Red Hat IPA team wants to implement an authority that reads authorizations from a centralized directory server. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME and non-linux platforms (release team please stand up)
On Thu, 2009-07-23 at 04:58 -0500, Brian Cameron wrote: Sun is already working to add DeviceKit support to Solaris It would be good to the devkit-devel mailing list know about this. Because if this is so, we need to change some of our plans; in particular move the make porting easier up the priority list. Also, I hope you guys know that PolicyKit is a not an optional dependency. Either way, even if you didn't want to contribute to DeviceKit-disks or DeviceKit-power, you can always just ship your own GVolumeMonitor implementation in a GIO module [1] and patch/reimplement g-p-m to use whatever. As I said in other mails, I don't think we ever want the core G stack to depend on something that only exists for Linux. [1] : This GVolumeMonitor implementation could probably use the same codebase as your excellent Fishworks product. Sun does not have much of an interest in shipping modules which have a strong dependency on PolicyKit No-one ever explained to me why Sun is suddenly not interested in this - and SUN did send patches to PolicyKit earlier on. The only explanations I've seen (in private mails) included childish statements like claiming PolicyKit is rubbish and that the author, me, didn't know what I was doing. Anyway, maybe you should ask someone at Sun out the latest polkit version http://hal.freedesktop.org/docs/polkit/ which is a complete rewrite of the old code. PolicyKit, by itself, is now merely an interface to interface to the authorization system - adding support for a Solaris RBAC backend amounts to subclassing a single class, implementing two methods and drop that code in an .so in $libdir/polkit-1/extensions. Yes, you're welcome that it is now this easy. (e.g. Sun is moving to use VisualPanels instead of wanting to ship GNOME system tools), and it typically isn't hard to make those few programs that use PolicyKit that we do want to ship use RBAC instead. Uh, RBAC just _doesn't_ do what a modern desktop needs. At least not last time I checked. The problem with Solaris RBAC, like many other authorization frameworks out there (I did an extensive analysis of many different authz frameworks some time ago), is that they really are not designed with the modern desktop in mind. Case in point, last time I checked out OpenSolaris (about a year ago so things might have changed) the whole package manager UI was a single process running as uid 0. Not only does this violate very fundamental security principles (least privilege etc.), it also messes up the user interface (theming, file chooser (root's home) etc.). And if you want a11y to work with such programs, then you effectively just extended uid 0 privileges to the rest of the desktop session. I am not sure what the big deal is here. Nobody from Sun has been complaining about GNOME being too Linux-ey, have they? Sun has always had a good relationship with the GNOME community, and it has never been particularly hard to get patches upstream to support things needed for GNOME to work well on Solaris or OpenSolaris. The perception, at least from me personally, is that Sun isn't doing a very good job at *working* with the GNOME community. Case in point, if RBAC or Visual Panels are oh-so-much-better, why the heck are you guys not trying to push it for non-Linux? And actually do the integration work inside GNOME instead of bolting your work on after the fact? That would benefit both Sun, the rest of the GNOME community and it would make you guys look a lot better. At least in my eyes. Btw, if you look at the Linux kernel community, behavior like this is frowned upon. So I don't think you should be too surprised that this is how some of us feels. Anyway, didn't mean to sound rude or too harsh, hope you guys will take this as constructive criticism. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME and non-linux platforms (release team please stand up)
On Wed, 2009-07-22 at 16:27 +0100, Calum Benson wrote: On 22 Jul 2009, at 15:56, Johannes Schmid wrote: OK, I can install all those in a virtual machine but just the amount of work I had to put in for basic testing cannot be really done in my free time. That's certainly true for many individual contributors, which is why I also said we ought to to figure out how to better distribute the development and QA workload to make that happen. However, for people who make their living developing GNOME software, IMHO it behooves them as professional open source software engineers to respect the requirements of the other people who will be using the code they write, insofar as those requirements are known up front. And right now, every professional GNOME developer knows up front that GNOME isn't confined to running on Linux, so that should figure fairly strongly into their design work. You know, maybe if the non-Linux platforms actually participated in _designing_ and _developing_ the core plumbing bits, threads like this wouldn't have to happen. My experiences from GIO, GVfs and HAL and other things pretty much sums up to this. 1. We find out we need some new plumbing bits to enable some kind of new exciting feature in GNOME. 2. Someone starts working on a Linux implementation of this. The interface is usually designed to be portable, but, hey, who knows. 3. GNOME is ported to using this new plumbing bit. After a while the plumbing bit matures and the new feature is being ironed out. Much rejoicing. 4. Someone from SUN finds out that the latest version of some GNOME doesn't compile on Solaris or work as advertised. Interesting bugs are filed. 5. Some manager at SUN decides Solaris needs this feature too 6. The porting effort is out-sourced to some group in SUN with people that are not really familiar with either a) the plumbing bits in question; b) desktop development or GNOME development in general This may be harsh but it's pretty much how I feel it works. It would be a lot better if non-Linux platforms, like Solaris is in this respect, actually started participating much earlier. You still have time for the DeviceKit-disks and DeviceKit-power stuff for example. Anyway, if SUN started changing this behavior then maybe it would be a lot easier to not feel incredibly insulted by statements like it behooves them as professional open source software engineers to respect the requirements. Because right now it's the pot calling the kettle black. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME and non-linux platforms (release team please stand up)
On Wed, 2009-07-22 at 15:50 -0400, Colin Walters wrote: On Wed, Jul 22, 2009 at 3:10 PM, Colin Walterswalt...@verbum.org wrote: I think it makes sense to continue to have GNOME work in the basic POSIX+X11 mode, i.e. gnome-power-manager just calls exit(0) if devicekit-power isn't running. But beyond that is hard. I should add that despite it being hard, the different interests here should try to have a constructive conversation about it. Some of this is more easily divisible than others; nothing directly depends on nm-applet, and most projects using say org.freedesktop.NetworkManager already have it conditional, and it's not hard to do. For other things like detecting a webcam device and using it...well...hard. Exactly. FWIW, I've been advocating for a while that, for example, GStreamer should aim to provide everything an application needs - ie. a complete framework. This came up when Cheese was being ported from HAL to use libgudev for device discovery. Now, the actual device interaction already happened in GStreamer, e.g. you use the v4l source and pass it a device file. But device detection etc. was missing. Having all that in GStreamer will make Cheese easily portable to Solaris, Windows, OS X and so on (and AFAICT these changes are happening in GStreamer so kudos to these guys). On a more general note, the way I'd like our platform story to end up is that GLib, GTK+ and GStreamer are the three only (sets of) libraries that people end up using. We're there already for storage/io devices (GVolumeMonitor) and networking (the networking/resolving bits that recently landed in GIO). The way it works for storage/io is through GIO extension points: - The interface library (GIO) provides default implementations (GUnixVolumeMonitor, GWin32DirectoryMonitor for example) - Modern desktop operating systems can be replace implementations with in 3rd party packages. We do this in GVfs - there's a HAL based volume monitor that works on Linux, FreeBSD and Solaris. In fact, thanks to this separation it was relatively straightforward to just make GIO use DeviceKit-disks instead of HAL. And Solaris and FreeBSD can keep using the HAL monitor while modern Linux distros switch to the DeviceKit-disks based on. (In fact, if the Solaris folks don't want to go through the effort of porting DeviceKit-disks (it's *hard* to port right now, something I as the maintainer will need to be involved in fixing), they can simply just write their own GVolumeMonitor implementation.) Another benefit of this separation is that we are less dependent on changes in one particular operating system. This is doubly-plus important in Linux where our current code depends on certain kernel API / details that are not stable. A concrete example is the proposed libata transition from the SCSI layer to the block layer. If each and every app had to look at sysfs themselves, we'd be in porting hell. To sum up, I guess I'm trying to say a couple of things here 1. We need to make our core libraries genuinely useful - e.g. we can't have them only do half of what apps need (e.g. Cheese) 2. We need to actually have some documentation telling app developers _what_ the core platform is. We have some of this already but, at least in my eyes, there's still too many libraries of varying quality. For 2., my view is very simple. a. Our platform is GLib, GTK+ and GStreamer (and probably cool things like Clutter when it's 1.0) b. Everything in the core platform _needs_ to work on all three major platforms: - POSIX/X11 - Windows - OS X c. Additional desktop integration is welcome (e.g. DeviceKit-disks based volume monitor) but things need to work without it Now, GLib, GTK+ and GStreamer aren't yet complete enough to do a complete desktop. But if you look at what's going on the past few years we are definitely going in this direction: - GIO landed - GNIO landed - Discussion/concrete code for GConf replacement (GSettings in GLib) - Discussion/concrete code for G-ish D-Bus library in GLib - Some people want power management interfaces in GTK+ - again, this can already be done with extension points - (e.g. the POSIX/X11 would ENOTSUP, Linux would use devkit-power, Win32 would use the Win32 API, OS X would use the OS X API) and so on. Oh, and there are some loose ends here like authorization, keyring and so on - we'd need to figure out what to do with them. And someone probably would want a HTML/JS stack too (maybe add WebKit to the stack, I don't know). So this is the vision: GLib/GTK+/GStreamer (and Clutter) is the proposed stack. And the proposal is that this stack runs on at least POSIX/X11, Win32, OS X. And that the stack is easily extensible so it works well under Linux, Solaris providing someone writes implementations of well-defined interfaces. Again, all this is not really a radical _new_ idea - I mean, most of this is already happening. But I think it
Re: GNOME and non-linux platforms (release team please stand up)
On Wed, 2009-07-22 at 17:36 -0400, Colin Walters wrote: On Wed, Jul 22, 2009 at 5:07 PM, David Zeuthenda...@fubar.dk wrote: I agree with a lot of what you say, except: b. Everything in the core platform _needs_ to work on all three major platforms: - POSIX/X11 This isn't a platform really. Which is really the entire debate here. They're enough, along with maybe a file monitoring API, to write the classic shared Unix server desktop, complete with file manager, clock, and panel. But beyond that - enterprise (let alone consumer) laptops in particular, no way. No, but it's a starting point. Just like GUnixVolumeMonitor is a starting point. And the same way GFileMonitor has a FAM backend (that FreeBSD is still using as far as I can tell). People can fill in the blanks with better implementations. If you guys working on DeviceKit-* are willing to have different backends, then that sounds fine. It's not a complete answer, but it fills in the massive gap that removing HAL left. If not, then we have to think about the story GNOME is going to tell here. We might but it's a lot of work. It is probably worth it. Maybe it just ends up being gnome-power-manager isn't even added to the session if there's no DK-power, and vendors have to fill in that gap on their own, i.e. it'd be renamed gnome-dk-power-manager, and someone else could come by and add a different daemon. It's important to make a clear distinction between apps and the G stack. For something like storage handling, every app needs it for the file chooser. And for things being able to implement a file manager. So we implement just enough of it in the G stack so it is useful. For example, Nautilus basically (that's a big basically, but...) only depends on GLib and GTK+ right now. But we don't offer enough API in the G stack to write e.g. Palimpsest Disk Utility - e.g. if you want to write a formatting tool, partitioning utility, whatever you need to depend on something outside the platform. It just means that ISVs can only write file managers and not advanced disk utilities. And that's fine. For power management, maybe we only offer basic API in the G stack to do what apps need: E.g. inhibit system suspend / inhibit screensaver. And, again, that's completely fine. We don't expect ISVs to be able to implement complete desktop environments. For Bluetooth, another Linux only thing for now, the answer is the same; we probably don't need Bluetooth specific APIs - mostly because we already abstract the useful Bluetooth stuff in GVfs and PulseAudio. For Audio, it is basically the same. Apps don't really *need* to care about whether it's Pulse/OSSv4 or whatever. They are supposed to be using GStreamer *anyway*. So we probably don't need to provide any API in the G stack except for things things like libcanberra which is already portable to whatever. Anyway, my main point is this: the POSIX/X11 target isn't so much about making GNOME, the desktop run on POSIX/X11. It's about making apps *built* for GNOME, the desktop, e.g. apps using only the G stack (e.g. GLib / GTK+ / GStreamer / Clutter / Webkit / whatever) run on any random POSIX/X11 system. Or any random Win32 or OS X system. In *addition* we could require that the basic desktop shell (core apps such as Nautilus, gnome-panel - gnome-shell in the future) needs to be pure apps - e.g. only rely on the G stack. We'd probably want that even if it means the basic desktop shell would run in degraded mode (e.g. missing functionality). This would of course also means that some apps that people think of as core GNOME apps, such as gnome-power-manager wouldn't really be pure apps (only using the G stack) insofar they would have strong deps on things outside the G stack (e.g. devkit-power). Again, that's completely fine. It's all about how we *frame* it - G Stack (runs on any target) - gtk+/glib/gstreamer/clutter/webkit/whatever - G apps (can only depend on the G stack) - panel, file manager, desktop shell - Value add apps (may be OS specific) - disk utility / formatting / etc. - power manager - volume control (highly OS specific) In my view this is very close to how things actually work. If we made something like this official we wouldn't have to waste time arguing whether the volume control is depending on PulseAudio or not of course it would leave vendors not shipping PulseAudio in the cold, but then again, these vendors can just work on their own volume control (or take the GStreamer one) and do whatever they want. That's completely fine. So all in all, this is basically proposing shifting more responsibility to the OS vendor. e.g. it would make it more difficult to get GNOME working out of the box unless you are willing to ship the latest bits. I, for one, think that is a *good* thing. Either you swim or you sink. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org
Re: GNOME and non-linux platforms (release team please stand up)
On Wed, 2009-07-22 at 23:29 +0100, Bastien Nocera wrote:
On Wed, 2009-07-22 at 18:17 -0400, David Zeuthen wrote:
For Bluetooth, another Linux only thing for now, the answer is the
same;
we probably don't need Bluetooth specific APIs - mostly because we
already abstract the useful Bluetooth stuff in GVfs and PulseAudio.
Actually, not quite. The BlueZ D-Bus API is already an abstraction of
the Bluetooth specs. You could implement that same API in another daemon
for use on other Bluetooth stacks.
Yeah. But right now it is Linux only und so weiter... If someone ports
Bluez to other platforms, or reimplements, then, hey, great, they can
take advantage of all the cool Bluez integration you have written. That
alone should be reason enough for them to do it. But things like this
just don't happen over night. It took 2+ years for a Solaris backend for
HAL to surface and another year or so for the FreeBSD backend.
My main point really is that we need to stop thinking of GNOME as a
whole desktop environment that will run everywhere and solve every
problem known to man. We need to stop bickering about really OS-specific
things such as volume controls. We need to make a distinction between
applications (the thing people actually use) and OS-specific conduits
(audio volume control, formatting a disk).
We need to focus hard on providing a set of rich, but lean and tightly
controlled (e.g. solid maintainers needed), introspectable libraries so
people can write useful _applications_ in their favorite language. And,
ideally, for any target. And, more ideally, so apps are relocatable (cf.
the recent thread on gtk-devel-list).
Further, we need to design these APIs so they are extendable. We want to
provide baseline functionality for the X11/target (GUnixVolumeMonitor)
while at the same time take advantage of the latest and greatest
OS-specific software (DeviceKit-disks monitor).
(And, for those of you still reading, GIO/GVfs is an _excellent_ example
of how to do this. Alex really got this right.)
That set of APIs will provide a good foundation so people can innovate
in areas like GNOME Shell, Sugar, whatever without having to worry about
a lot of things.
(Of course we still need to care about system integration, e.g. the
whole DeviceKit-{disks,power}, PackageKit, Pulseaudio, Bluez story. But
it really shouldn't be anything that affects the G stack except that it
might optionally use parts of it in certain place. And we might use it
in apps that are not pure G apps - e.g. Bluez desktop integration,
Volume Control, Palimpsest and so on.)
David
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3 status update
On Sat, 2009-06-20 at 16:15 +0200, Andre Klapper wrote: = Complete migration from HAL to DeviceKit-* by 2.27.3 This also includes libudev/libgudev - the latter is available in udev = 143 which was just released. = NOT COMPLETED. According to jhbuild rdepends hal --direct the following modules still depend on HAL: * brasero: http://bugzilla.gnome.org/show_bug.cgi?id=581742 * cheese: http://bugzilla.gnome.org/show_bug.cgi?id=583640 * gnome-power-manager FIXED: http://bugzilla.gnome.org/show_bug.cgi?id=565867 Also, gvfs needs porting but Martin Pitt is on top of this: http://bugzilla.gnome.org/show_bug.cgi?id=586410 http://bugzilla.gnome.org/show_bug.cgi?id=586409 I'll review and commit Martin's patches shortly. * Porting to PolicyKit 1.0 PATCHES awaiting review/commit: gdm, gconf, gconf-editor, gnome-applets, gnome-panel, gnome-session With PolicyKit 1.0, the model has changed [1] insofar that we don't need to make clients of mechanisms using PolicyKit aware of PolicyKit itself. So the port, GNOME-wise, actually only includes ripping out support for PolicyKit, in particular the libpolkit-gnome.so.0 library which is no more. There are a couple of pieces of GNOME software where we also provide our own mechanism - GConf is one of those. But with the way things work, this dependency isn't exposed in any public API, e.g. it's possible to port the GConf defaults mechanism to use another authorization framework if the OS happens to supply one. Finally, there is still a polkit-gnome project. This package contains a PolicyKit Authentication Agent (to pop up authentication dialogs when needed) and will also contain a tool to modify the local authority (not yet written but will be done before 2.28). This project does not provide any API, only said Authentication Agent and the tool. FWIW, Matthias done a great job both porting apps as well as creating / maintaining this page http://fedoraproject.org/wiki/Features/PolicyKitOne which is useful for both distributors and the GNOME project itself. I guess all this means that PolicyKit doesn't even need to be an external dependency anymore; e.g. basically no apps need to be aware it even exists. Hope this clarifies. David [1] : See http://hal.freedesktop.org/docs/polkit/PolicyKit-1.8.html for more information about how this works. In particular this change means that our GNOME software is much more portable insofar that OS vendors / distributors / sites / etc. can plug in their own implementation of the Authority. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new dependencies in gvfs
On Mon, 2009-06-01 at 22:13 +0200, BJörn Lindqvist wrote: Here is the point, as I see it. g-d-u is proposed for inclusion in 2.28. Please read http://mail.gnome.org/archives/desktop-devel-list/2009-May/msg00016.html where I've already stated upfront that the deps for gnome-disk-utility is bleeding edge, why this is so and why that won't change. Also note that the proposal for inclusion of gnome-disk-utility in 2.28 is dependent on this not being a problem. If it's a problem, maybe we shouldn't consider gnome-disk-utility at all for 2.28 (I'm not in a hurry to finish it anyway; it will see API breakage for a while). If distros, such as Fedora, wants to use gnome-disk-utility they can just include it themselves. And jhbuild / more conservative distros can use the HAL GVfs backend, it works just fine. Of course there's a bunch of features / stuff you won't get but such is life if you are using a conservative distro. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.0 - shell and applets
On Fri, 2009-05-15 at 01:58 +0200, Luis Menina wrote: Toms a écrit : 1) System tray - applets that could end up in system tray, most probably contextually - like, when they are needed or make sense. Or, sometimes per user request in preferences (something like a show in system tray checkbox for those marginal nobody knows cases). As pointed out[2], KDE has some specs worth considering on the case. Please, don't try to abuse the system tray for things that should be applets. System tray has been made to notify events. One should be able to use GNOME without requiring a notification applet. Actually it's a real pain trying to support tweakers and enthusiasts that, for one reason or another, don't have a notification area. A couple of examples 1. In gnome-disk-utility we put an icon in the notification area to tell people that their disks are failing, see http://people.freedesktop.org/~david/gdu-ata-smart-notification.png http://people.freedesktop.org/~david/gdu-ata-smart-warning.png We also show a libnotify notification pointing to this icon. In fact, we don't show this notification if you don't have a notification area; I mean, we'd need to reword the libnotify notification (make it longer, bad) and also provide buttons to get the user to the app showing details. In other words, what was previously a clear warning turns into something that is pretty close to an UI disaster. 2. For PolicyKit, we want to convey the user that the user is running with elevated privileges (so they can throw these privileges away if desired). Without a notification area, you obviously won't get this icon. It's not hard to come up with other legitimate examples (package management for example) of why a notification area is useful. Anyway, my stance on this is very clear: I will not support users without a notification area, I'm just not going to add code and mess up the UI just to support people who don't use a notification area. (And, FWIW, I'd wish we had a better way in GNOME of providing the information discussed above to the user - e.g. I'm not saying the notification area as it is _today_ is very good.. but at least it gets the job done.) FWIW, I wholeheartedly agree that lots of people abuse the notification area. And I'd like to point out that your own application is doing this, here's a screenshot I did a few weeks ago http://people.freedesktop.org/~david/brasero.png because the whole user experience was so.. freaking absurd.. and I was overloaded with redundant information. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.0 - shell and applets
On Fri, 2009-05-15 at 18:58 +0200, Frederic Peters wrote: David Zeuthen wrote: FWIW, I wholeheartedly agree that lots of people abuse the notification area. And I'd like to point out that your own application is doing this, here's a screenshot I did a few weeks ago Oh that may explain why Jon also pointed to Brasero. Luis Menina != Luis Medinas. Yeah, Hubert just pointed this out to me on IRC and now I feel really stupid. Sorry Luis! David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new dependencies in gvfs
On Sun, 2009-05-03 at 07:57 +0200, Frederic Peters wrote: I am all for DeviceKit-disks as an external dependency, but don't we want gnome-disk-utility as part of the desktop set ? It features many things, notifications, Nautilus extension, awesome replacement for gfloppy, and more, things that definitely have their place in the desktop. Just like Emmannuel I'd love to have it in the desktop suite. And being a whole part of the GNOME desktop was what I understood from David announce[1] (but then I could have read too much in this): This will be the default volume monitor in GNOME 2.28 David, would you formally propose gnome-disk-utility for inclusion in the GNOME Desktop Suite ? Sure, that sounds sensible. The long term plan of this work is to have - two libraries, libgdu and libgdu-gtk - a set of applications / utilities - deep integration with GNOME (e.g. Nautilus extensions, panel items / applets, GVfs volume monitor) for dealing with storage devices. The idea is that the bulk of the work is in the libraries (including GTK+ widgets and dialogs) thus allowing people to experiment and iterate over what kind of end-user experience we want. I'm not yet ready to commit to any kind of stable API (yet) but that shouldn't be a problem as we can just update GVfs et. al. along and AFAIK there's no guarantee of any API stability in Desktop, only in Platform. However, one thing is that the (D-Bus) API of the daemon being used, DeviceKit-disks will remain API unstable for a bit longer (long term plan is to provide a stable API) - probably until the GLib/D-Bus story is sorted (see e.g. gtk-devel-list) and we have other backends (I want a backend for unit tests and of course ideally FreeBSD, Solaris and others could write backends too). This Device-disks is API unstable might be a hard pill for some distributors to swallow, e.g. they would need to rev DeviceKit-disks whenever a new GNOME release is out. Which includes revving things using DeviceKit-disks as well (it's not unlikely KDE and others will switch to DeviceKit-disks at some point). Also, the requirements for running DeviceKit-disks is also going to remain bleeding edge - to do integration on the level we want (e.g. do it right, for starters), we really need to depend on kernel and udev features as we add them. These shouldn't be problems for most distros, e.g. Fedora, OpenSUSE, Ubuntu, Mandriva etc. all tend to ship bleeding edge stuff _anyway_. It might be a problem for other OS'es (DeviceKit-disks is Linux only at the moment), jhbuild users and infrequently release distros (such as the enterprise releases or Debian). The only answer I have to this is that I will ensure that things (like GVfs) will build with --disable-gdu and then people can fall back to e.g. the HAL backend or whatever. With the caveat that these things will not be problem (because, no, I will not spend time making things work on ancient kernel or udev releases) for inclusion in the Desktop release set, I'd be more than happy to propose gnome-disk-utility. (Btw, it's not like DeviceKit-disks is in any way special here - these things apply to _many_ bits of an OS too (e.g. graphics, audio) - I'm just trying to be upfront about these things in order to manage expectations.) Finally, minor technical point: it requires libsexy (for SexyUrlLabel). I can ship a local copy if this isn't in GTK+ by the 2.28 release (I believe the plan is to get something like this into GTK+). David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.26 module inclusion discussion heats up
On Fri, 2009-01-16 at 17:12 +0100, Josselin Mouette wrote: Le vendredi 16 janvier 2009 à 10:55 -0500, Matthias Clasen a écrit : But this is not a runtime decision. Either your distro is using pulseaudio (and it should) Again, this cannot be a distribution choice! We can ship PA by default and make everything possible to get the best of it, but breaking systems where it is not installed is not an option, given the number of setups that don’t work with it. Listen, to repeat what Matthias said: either you ship PA and make it work. Which includes sending patches to the PA folks. Or you don't ship PA. It's pretty simple. I'm not sure why you think that Debian should get a wild card here so it can push the decision of whether to use Pulse Audio to the user. Which, IMNSHO, isn't the best way to develop an operating system. But, hey, it's your operating system, do whatever you want. But please don't hold the rest of us hostage to such development practices. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME DVCS Survey Results
On Sun, 2009-01-04 at 17:48 +, John Carr wrote: As bkor has stated, there are lots of Git users so any implementation will support you, and support you well. That is a requirement. So any talk of my idea is not Git vs Bazaar, its talk of one way we can move forward. So i dont consider it to be derailing. When mentioning my idea, lets stick to technical problems with it rather than trying to undermine anyone who has looked at it and thinks it is sound and doable. Can you explain what would happen in the event that a future version of git switches to an repository format that isn't compatible with how you want to store data? David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME DVCS Survey Results
On Sun, 2009-01-04 at 23:01 +0200, Zeeshan Ali (Khattak) wrote: How about we set-up a task-force of volunteers who would want to help in the move, each volunteer promising at least 3 hours a week? 3 hours is a very small amount of time but I am hoping that we'll be able to gather at least 10 volunteers and together we can do it, even using our spare time. Would it be worth investigating whether it's worth having the Foundation pay someone to help with this migration (planning, executing, maybe even hosting etc.)? I mean, the eco-system around git is huge (github and others comes to mind) and growing... I'm pretty sure there's plenty git experts around. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME DVCS Survey Results
On Sun, 2009-01-04 at 22:47 +0100, Frederic Peters wrote: Probably just like bzr already went through several repository formats and allowed easy upgrades (just like Subversion repository format changed and it didn't cause any problem for users). I don't think there is a problem here. I don't find this answer compelling. At all. It also doesn't answer the question. It's not unlikely that a future git repo format is fundamentally incompatible with current or future bzr repo formats. And also, data would be available in native git format on lots of computers, and could always be pushed to a vanilla git server. Someone really got to explain exactly why support for multiple repository formats is desirable. First, it only makes it much harder for users to grasp; we're going to end up with some projects have l.g.o pages / README files / mailing list messages saying use bzr to check out this branch and others saying the same for git. That's *not* desirable; it makes it so much harder for new contributors. Second, it also makes it harder to set up things like jhbuild; either you end up pulling from both git and bzr (from the same underlying repo) or you end up mentally having to translate branch names etc. from one system to another. This is error prone. Third, I could go on with examples, just consider the set of webtools (cgit, annotation, source code searching etc.) we end up with on dvcs.gnome.org; some would be built against bzr, others against git. You get inconsistent branch names, you end up overloading contributors with different concepts and so forth. Finally: We're talking about people's data here. The first rule of holding peoples data is that you don't screw around with it just because. Data integrity matters. Keeping things simple and staying with a *single* kind of hammer (instead of a weird homegrown mutant hammer) helps here. Otherwise we end up with data loss. Frankly, I'm concerned that some people are even considering using such homegrown kludges for holding our GNOME source code. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME DVCS Survey Results
On Sun, 2009-01-04 at 23:20 +0100, Ali Sabil wrote: First, it only makes it much harder for users to grasp; we're going to end up with some projects have l.g.o pages / README files / mailing list messages saying use bzr to check out this branch and others saying the same for git. That's *not* desirable; it makes it so much harder for new contributors. That's not what John's proposal is about ! John wants to use the bzr format as a repository format, and add a git-serve plugin to bzr to be able to talk to the git clients. In other words, you will be able to access the same data using either bzr, git or hg. Uh, but that's exactly how I understood the proposal and I believe that the points I made (that you didn't respond to) still stands: That it's crazy to officially want to support git, bzr and hg *at* the same time *from* the same repo. It's just asking for trouble. Finally: We're talking about people's data here. The first rule of holding peoples data is that you don't screw around with it just because. Data integrity matters. Keeping things simple and staying with a *single* kind of hammer (instead of a weird homegrown mutant hammer) helps here. Otherwise we end up with data loss. Frankly, I'm concerned that some people are even considering using such homegrown kludges for holding our GNOME source code. Comparing the size of the Bazaar unit tests with those of Git, I would certainly choose Bazaar for storing my data. I wasn't commenting on bzr vs git storage format; I'm sure either is fine. I was commenting on the fact that someone proposes to inject something like git-serve in the middle; that's what I think is a kludge. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME DVCS Survey Results
On Sun, 2009-01-04 at 23:33 +0100, Olav Vitters wrote: On Sun, Jan 04, 2009 at 05:29:02PM -0500, David Zeuthen wrote: Uh, but that's exactly how I understood the proposal and I believe that the points I made (that you didn't respond to) still stands: That it's crazy to officially want to support git, bzr and hg *at* the same time *from* the same repo. It's just asking for trouble. That isn't true. It is Bzr on server, with Git support. Nothing about Hg, nothing about doing partly Git, partly Bzr. Then what happens when a new version of git with a new feature, incompatible with the git-serve kludge, is released? Then we're screwed, right? And who gets to pay? We do. We're stuck with an old version of git. Us. The very same people who very clearly said git, not bzr. Is it *really* so hard to understand that this whole git-serve is a terrible idea? David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME DVCS Survey Results
On Sun, 2009-01-04 at 23:58 +0100, Olav Vitters wrote: On Sun, Jan 04, 2009 at 05:40:18PM -0500, David Zeuthen wrote: Is it *really* so hard to understand that this whole git-serve is a terrible idea? You expect me to reply to this??!? I expected you to reply to the other three mails where I asked the same thing as I did in the mail you replied to. Oh, you chose not to quote that; here it is again: Then what happens when a new version of git with a new feature, incompatible with the git-serve kludge, is released? Then we're screwed, right? And who gets to pay? We do. We're stuck with an old version of git. Us. The very same people who very clearly said git, not bzr. But, alas, you didn't reply to this. You instead hand-waved about something else. I don't think I breached any code of conduct, written or otherwise, by displaying my frustration about how you are evading my question. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME DVCS Survey Results
On Mon, 2009-01-05 at 00:18 +0100, Olav Vitters wrote: I am not evading. Stop trying to make this personal. I don't care about CoC, I don't like you're talking to me. Please. Stop trying to make this look like it's personal and like I'm assaulting you. Because I didn't. And I resent the accusation. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Eel merged into Nautilus 2.25.3
On Mon, 2008-12-15 at 21:44 +0100, Andre Klapper wrote: $:andre\ jhbuild rdepends --direct eel nautilus orca meta-gnome-desktop-suite gnome-mount Just for the record, for gnome-mount there's no direct dependency on eel; there is, however, a dependency on libnautilus-extension (which I think in turns (used to) depend on libeel). HTH. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: gnome-user-share
On Fri, 2008-10-24 at 15:16 +0200, Josselin Mouette wrote: I also think that Apache is a bad choice. If you need a good web server with DAV support, please think of lighttpd instead, or - much better - of a libsoup-based implementation. There's also security issues to consider. One good thing about using Apache is the fact that there's a huge dedicated security team in place for both reviewing and dealing with vulnerabilities in highly predictable ways. Also, the distributors of Apache typically provide good response time on integrating these fixes just because Apache is so ubiquitous and people use it for traditional HTTP duties on port 80. Especially on distributions not using something like SELinux this is a problem. Remember that with Mandatory Access Control (which e.g. SELinux provides), you can confine the web server process spawned by g-u-s to only access ~/Public. Without something like this (and too many people, yours truly included, runs SELinux in permissive mode)... if there's a vulnerability in the server used by gnome-user-share... then you're effectively serving all the files that the user has access to (e.g. $HOME including passwords stored in cleartext by Firefox (the default). Result: Game over man! All thismeans that it's very important that we use the most secure web server we can get for gnome-user-share. As I said, it's clear to me that Apache does meet our goals here. If you want to propose something else, the burden is on you to provide evidence that what you propose is not only reasonably secure, but also have good processes in place for dealing with vulnerabilities. (FWIW, I don't mean to belittle libsoup-as-a-server (my understanding is that libsoup is mostly used as a client so that's where the focus is) or the lighttpd teams. To be honest, I haven't looked at their security track record security. I doubt most people in this thread have.) David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: gnome-user-share
Hi, FWIW, this discussion happened about four years ago, see http://mail.gnome.org/archives/desktop-devel-list/2004-November/msg00726.html (note: the thread continues into December 2004) It might be useful for people to reread the thread there. On Thu, 2008-10-23 at 17:15 +0200, Patryk Zawadzki wrote: As a data point, Fedora's httpd is disabled by default for exactly this sort of reason (having it installed doesn't mean we want it running by default). I doubt our server guys will get overly happy over the idea of disabling a typical server daemon just so you can integrate it with GNOME. I don't really think I want the server team to hate the GNOME team any more. So one conclusion from that thread, if I remember correctly, is that the fact that gnome-user-share is using Apache shouldn't disrupt any system-wide configuration of Apache. The way it works is that gnome-user-share feeds a separate configuration file to the Apache HTTP daemon running in the user context. The fact we disable httpd in the default install in Fedora has nothing to do with this; that's just Fedora policy, off topic for this discussion. As a data point we've been shipping gnome-user-share in Fedora since 2004 and haven't had issues with it or complaints from people using Fedora as a web server. Hope this helps. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-volume-manager disables automount
On Fri, 2008-08-15 at 18:27 +0800, jijun yu wrote: gnome-volume-manager disables automount by default. The reason is that Nautilus handles it, as it said in configure.ac. But after a rough investigation, nautilus don't handle automount. So I'm a little confused here. This works just fine on Fedora and other Linux distros. File a bug against nautilus with more details and add me to the Cc? David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed external dep: PolicyKit
Hi, (adjusting Cc list) (Polite request: please avoid sending HTML mail) On Mon, 2008-07-21 at 22:34 -0500, Jason D. Clinton wrote: On Fri, Jun 20, 2008 at 1:47 PM, David Zeuthen [EMAIL PROTECTED] wrote: On Fri, 2008-06-20 at 15:57 +0200, Murray Cumming wrote: Going off topic a bit: It would be really nice if PolicyKit had a proper web page and mailing list. It's too important for information on it to be so fragmented. Right. I'm actually going to try and fix this (dedicated mailing list and website); stay tuned. JFYI there is now http://lists.freedesktop.org/mailman/listinfo/polkit-devel http://www.freedesktop.org/wiki/Software/PolicyKit and has been for some time. There's been a bugzilla on fd.o for a long time. I am tracking relatively unstable development repositories. As a result, I have hal 0.5.11 installed which appears to have--undocumentedly--suddenly required PackageKit as a hard dependency. For example, removable storage mounting no longer works if PK is not installed due to the way that the default dbus fdi rule is written. News to me, it's still optional according to the NEWS file http://gitweb.freedesktop.org/?p=hal.git;a=blob;h=9dadda7da29d4c18dff6e71d343cd5eb69561c56;hb=95bd4f1bf9a62f1551461841d64f6f1cdea6a92e;f=NEWS Did you file a bug or complain on the hal mailing list? This mailing list is not the right place to complain about it anyway. Aside from the hal harddep problem, it appears that PK is sorely, sorely missing its documentation. For example, having this new dependency thrust upon me would have been fine if things like /usr/share/doc/policykit-gnome/README didn't contain: TODO: write me If RH is going to thrust PK on us, please, please, please provide some kind of documentation (not an API reference). When things don't work (as they aren't now and were previously) I have absolutely no idea what's wrong, where to look or who to blame. Most importantly, I wanted to file a bug but couldn't even manage that with the spectular lack of information out there. There's this http://hal.freedesktop.org/docs/PolicyKit/ http://hal.freedesktop.org/docs/PolicyKit-gnome/ (and this is even an older snapshot of what comes out of the tarballs) which is much more than API reference etc. Did you even read it? FWIW, all the distros and even advanced users with building from scratch with weird configuration permutation like you have not whined/complained in the same way I'm seeing here. For them PolicyKit just works and adds value. Hell, some KDE people wrote their own Authentication Agent that uses Qt and KDE. So it's not like it's a huge mystery what PolicyKit-gnome does. If you're not able to figure it out given the code and existing docs then you probably never will. Anyway. (Even users from some of the historical problematic distros like Slackware (as in usually outdated libc headers, no PAM etc.) can make this work for them.) So maybe you just haven't tried hard enough. In other words, I believe it's more of a you-problem, than a PolicyKit problem. Either way, this thread / mailing list is not the right place to ask for help, use the polkit mailing list. Also send patches if you think the existing docs are not good enough; some of the docs could surely use some improvement. After all, this is open source and all, no one promised you a pony etc. etc. Luckilly, Rob Taylor was gracious enough to point me in the right direction from what he has in his own memory. Alas, correcting for an obvious packaging error hasn't solved to problem so I'm stuck again. I'm sure others would not be even this fortunate... I'm sure others would have used the appropriate forum, not some random thread on a somewhat unrelated GNOME mailing list, and they would have gotten the help they needed. I'm also sure they would have been precise about what was wrong instead of just whining. (And, while we're at it, here's some more advice: please cut the company-bashing (If RH is going to thrust PK on us...) and drama. It's really off-putting and it makes it hard to take you seriously.) Good luck, David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Problem with intltool 0.40.0?
On Thu, 2008-07-10 at 11:14 -0400, David Zeuthen wrote: On Tue, 2008-07-01 at 17:01 -0400, Colin Walters wrote: Options: o Rename intltool to intltool2, allow parallel install with intltool 1 o Add backwards compatibility support o Don't screw with minor build system things right now, and wait a year or so until waf is widely deployed, then switch wholesale and gain useful improvements instead of plugging a one small leak in the sinking shell script mess of auto* Can the release team please advise on this? (for example mandate that we're using intltool 0.40 for 2.24). FWIW, the thread starts here http://mail.gnome.org/archives/desktop-devel-list/2008-July/msg00011.html Thanks. It's now been 12 days since I sent this mail and I've received no reply. Is it possible for the release team to advise on how to proceed on dealing with the incident of ABI breakage? Thank you. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed external dep: PolicyKit
On Tue, 2008-07-22 at 18:40 -0500, Jason D. Clinton wrote: Fuck you. I don't think so. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Problem with intltool 0.40.0?
On Wed, 2008-07-23 at 01:27 +0200, Vincent Untz wrote: Sorry, your mail was lost in the GUADEC black hole (at least for me). Yea, I probably chose the worst time to send it. Unfortunately, using intltool 0.40 for 2.24 would be a big pain too, since many modules already migrated for 2.23.4 a month ago. I didn't think hard about all this, but I'd think that offering a migration path for 6 months (making it possible to use the old way and the new way) would be the best option. Something that preserves backwards compat would be nice as this is going to make it somewhat nasty to take an app adapted to use intltool = 0.40 and build it on a distro that ships intltool 0.40. So this is definitely going to make backports of newer versions to enterprise and LTS distros somewhat harder I think (but I haven't done a full analysis of the problem). Colins idea about making a parallel-instable intltool2 would have solved this problem. I still think that's the way forward. Also, I think, it sets an ugly precedent to break build-time ABI stuff very randomly like this. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed external dep: PolicyKit
On Tue, 2008-07-22 at 19:11 -0500, Jason D. Clinton wrote: The issue is that there is no user documentation at all. Not in the distribution. Not in the GUI with a Help button. Not in stub README files. Nothing. ... Nothing? Did you even look at the links I sent in my last mail? Your statement is simply false. Here are plenty of non-API docs. http://hal.freedesktop.org/docs/PolicyKit/ref-design.html http://hal.freedesktop.org/docs/PolicyKit/tools-fileformats.html http://hal.freedesktop.org/docs/PolicyKit-gnome/ref-auth-daemon.html (granted there should be links from the website) Send patches / file bugs if you want to see more docs / improvements. As I said on IRC I'll still help you (or any other PolicyKit user) as long as you state what the problem is. Even after being verbally assulted and all. Unless you're a programmer and want to read developer documentation to get your USB hotplug working again. Or, you know, like the rest of the world use a distro if you don't want to compile things on your own. Listen, I'm not trying to belittle you; it's just a fact that it's getting increasingly hard for people to assemble all the random pluggable stuff that makes up the GNOME desktop. Again, I'd like to point out you're not using the optimal forum to get help. You're just lucky that I still reply to a thread that is off-topic for this list. The best way to get help is by using http://bugzilla.gnome.org/ - for PolicyKit-gnome bugs + features https://bugs.freedesktop.org/ - for PolicyKit end-user bugs http://lists.freedesktop.org/mailman/listinfo/polkit-devel Hope this helps. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed external dep: PolicyKit
On Tue, 2008-07-22 at 19:24 -0500, Jason D. Clinton wrote:
If that's your policy, then you need to
patch /etc/dbus-1/system.d/hal.conf to NOT use PolicyKit in a package
that doesn't have support for it.
There's no way to specify in a D-Bus .conf that it uses PolicyKit or
not.
This is--AFAICT--an upstream bug in hal that this stanza is not
removed when ./configure finds that PK is not going to be enabled. Now
THAT is a bug I could file.
Except (but now guessing at what you think is a bug) that it's not a
bug; see
http://gitweb.freedesktop.org/?p=hal.git;a=blob;h=503c09db191dac147cbb6616991a789cdecd265c;hb=95bd4f1bf9a62f1551461841d64f6f1cdea6a92e;f=configure.in
specifically this part
if test x${msg_polkit} = xno; then
echo WARNING: PolicyKit is disabled. You need to manually edit the hal.conf
echo file to lock down the service. Failure to do so allows any
echo caller to make hald do work on their behalf which may be
echo a huge SECURITY HOLE. I repeat: YOU NEED TO EDIT THE FILE
echo hal.conf to match your distro/site to avoid NASTY SECURITY
HOLES.
echo
fi
Anyway, this conversation should probably continue in the Debian BTS.
Feel free to Cc [EMAIL PROTECTED] if you need my input.
David
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Problem with intltool 0.40.0?
On Tue, 2008-07-01 at 17:01 -0400, Colin Walters wrote: Options: o Rename intltool to intltool2, allow parallel install with intltool 1 o Add backwards compatibility support o Don't screw with minor build system things right now, and wait a year or so until waf is widely deployed, then switch wholesale and gain useful improvements instead of plugging a one small leak in the sinking shell script mess of auto* Can the release team please advise on this? (for example mandate that we're using intltool 0.40 for 2.24). FWIW, the thread starts here http://mail.gnome.org/archives/desktop-devel-list/2008-July/msg00011.html Thanks. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Problem with intltool 0.40.0?
On Tue, 2008-07-01 at 11:31 -0500, Brian Cameron wrote: Yesterday I discovered that make dist/distcheck in gdm 2.20 branch failed because make couldn't find intltool-merge.in, intltool-extract.in, and intltool-update.in. These files get generated by the intltool module. Apparently what you are experiencing is a bug fix http://bugzilla.gnome.org/show_bug.cgi?id=490620 Personally I think the new behavior is bug. And further I think it's silly. Because now every user of intltool get to fix his module and distributions get to add something like BuildRequire: intltool to their spec files or similar. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Problem with intltool 0.40.0?
On Tue, 2008-07-01 at 14:58 -0500, Brian Cameron wrote: David: So what does this mean? Should all GNOME modules fix their top-level Makefile.am files, manpages, and other docs that refer to the need to add these generated files to EXTRA_DIST? Or do we just not work with the latest intltool 0.40.0 for now until this issue gets fixed in intltool? I'm not sure - but like you, my modules now fail to bootstrap (e.g. autogen.sh) with intltool 0.40. Better ask the intltool maintainer what he had in mind. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-session proposal
On Thu, 2008-06-26 at 14:16 +0200, Rodrigo Moya wrote: KDE applications are still using XSMP AFAIK, so we'll need to support it in some way We do? What happens if we decide not to? David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-session proposal
On Thu, 2008-06-26 at 18:02 +0100, Alan Cox wrote: It's far from an edge case. Any situation with two monitors side by side of 1024 pixel width causes the problem. Thats a pretty normal setup for anyone doing art design, engineering or similar work. Indeed. (And yes I agree the hardware/drivers need to catch up ;)) Right, and it works fine in Windows Vista. IIRC Adam Jackson was working on that a while ago, see http://www.x.org/wiki/Events/XDC2008/Notes and search for shatter. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-session proposal
On Thu, 2008-06-26 at 23:46 +0200, Frederic Peters wrote: Yes we do; at least I believe so. I won't complain about my xterms as they may be considered a legacy application but modern applications written for the other major free desktop should not be left in the cold. Do you have a concrete example of a modern desktop application where the absence of XSMP in GNOME 2.24 would be a huge inconvenience? David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-session proposal
On Fri, 2008-06-27 at 01:08 +0200, Frederic Peters wrote: David Zeuthen wrote: Yes we do; at least I believe so. I won't complain about my xterms as they may be considered a legacy application but modern applications written for the other major free desktop should not be left in the cold. Do you have a concrete example of a modern desktop application where the absence of XSMP in GNOME 2.24 would be a huge inconvenience? I think you should not limit yourself to GNOME 2.24; people are using other applications. Uh, I think you misread what I said. I was asking for examples of modern desktop applications (e.g applications using e.g. Qt, GTK+, Swing, SWT, E17, wxWidgets, XUL etc.) for which absence of XSMP would be a huge inconvenience. Do you have any such examples? David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Composition [was Re: gnome-session proposal]
On Fri, 2008-06-27 at 00:59 +0200, Patryk Zawadzki wrote: Well even if you try to read just a 10k file you can get stuck if another application is causing excessive IO (and I tend to run such applications). It's hard to delegate each disk operation to a separate thread just in case the computer is busy with something else. Get a better kernel then ;-). On a more serious note, didn't the recent Firefox 3 O_SYNC fiasco on Linux make some file system developers realize some short comings of current state of the kernel? If so, hopefully someone is working on fixing this. If not, definitely something to bring up at the Plumbers Conference later this year. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed external dep: PolicyKit
On Fri, 2008-06-20 at 15:57 +0200, Murray Cumming wrote: Going off topic a bit: It would be really nice if PolicyKit had a proper web page and mailing list. It's too important for information on it to be so fragmented. Right. I'm actually going to try and fix this (dedicated mailing list and website); stay tuned. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed external dep: PolicyKit
On Wed, 2008-05-07 at 17:27 +0200, Vincent Untz wrote: Le mercredi 07 mai 2008, à 16:18 +0100, Richard Hughes a écrit : I would like to propose PolicyKit[1] as an external dep for 2.26 - it's mostly API stable[2], and is now being used as an optional dep in many modules in gnome svn and HAL. s/2.26/2.24/ I guess? :-) Makes sense to me. Right, I did mention six months ago I wanted to propose PolicyKit-gnome for 2.24. That didn't happen for a number of reasons, none of them including the code not being ready; it's already in use in a number of places and shipping in a lot of distributions. There's also resp. Solaris and FreeBSD support in resp. 0.8 and git HEAD of PolicyKit. FWIW, my plan is to work on getting PolicyKit to 1.0 over the summer and then propose PolicyKit-gnome for Desktop in 2.26 and possibly for Platform in 2.28. I think, based on the number of apps using PolicyKit already, it would be nice to have PolicyKit 0.8 and PolicyKit-gnome 0.8 as blessed external deps for GNOME 2.24. How about that? David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed external dep: PolicyKit
On Wed, 2008-05-07 at 17:29 +0200, Murray Cumming wrote: On Wed, 2008-05-07 at 11:23 -0400, Matthias Clasen wrote: On Wed, May 7, 2008 at 11:18 AM, Richard Hughes [EMAIL PROTECTED] wrote: I would like to propose PolicyKit[1] as an external dep for 2.26 - it's mostly API stable[2], and is now being used as an optional dep in many modules in gnome svn and HAL. I would like to depend on it for gnome-power-manager, and I hate all the #ifdefs. Does anybody have any problems with PolicyKit being an external dependency in 2.26? From a user point-of-view PolicyKit rocks. It would be great if more GNOME software could be comfortable using it upstream rather than being patched by distros. Actually, the patches are using PolicyKit-gnome, too. If we allow dependencies on PolicyKit, we should allow PolicyKit-gnome, too, since it makes it very easy to write UIs that trigger privileged operations and handle all aspects of PolicyKit integration correctly. Yeah. Direct use of the PolicyKit D-Bus API (as is currently necessary from Python, for instance) is a bit strange, not documented, and is apparently not really supported. I haven't used PolicyKit-gnome but that should shield people from this. I'd like to see python bindings for it. Actually Harald Hoyer is working on python bindings for the core PolicyKit library. I expect this to be in the 0.9 release. I don't know about PolicyKit-gnome; it should be simple as the main thing there is just a GtkAction derived class. But I don't know a lot about how bindings are done. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Problem with thumbnail mamagement for image files
On Sat, 2008-03-15 at 13:40 -0500, Diego Escalante Urrelo wrote: On a side-note, it looks like nautilus doesn't generate thumbnails for trash:/// obex:/// and others, no matter the preferences set in nautilus. Regression or intentional? It's because someone didn't apply the patch here http://bugzilla.gnome.org/show_bug.cgi?id=517276 David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: help sanity check the release notes
On Wed, 2008-02-27 at 22:04 +0900, Davyd Madeley wrote: All, Because my GNOME 2.22 isn't actually working very well, the release notes currently contain a lot of FIXMEs and XXX entries. This is suboptimal. Might want to mention, under Better Networked Filesystems, that we now support - cdda:// - audio tracks on Audio CD's are available as .wav files; and - gphoto2:// - for digital cameras that are not mass storage out of the box (though you may want to avoid technical terms like cdda:// and gphoto2://). These are pretty visible end user features; we didn't have this in upstream builds of gnome-vfs. Perhaps it's also worth mentioning that Nautilus now handles automounting/autostart in a much shinier way that g-v-m did (see #510319 for details including lots of screenshots) including Cluebar support and the ability for apps to easily participate in this via setting a mime type. (And hopefully we can completely remove g-v-m for 2.24.) David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: help sanity check the release notes
On Wed, 2008-02-27 at 20:28 -0500, Hubert Figuiere wrote: Why not using camera:// ? Because it might conflict with another camera gvfs backend we might want to add in the future? And you could aslo add support for Mass Storage camera at the same time so that it be unified. Two way to do that: just rebind the mounted device or use the disk: driver in gphoto2. Why would we ever want to do that? It would dog slow and the gphoto2 API is a bit craptastic; you can't do partial reads etc. etc. Besides, Mass storage cameras already work very well using the kernel mass storage drivers. Note that we had a FUSE filesystem for a while, so it feels like NIH again and again. POSIX is a really poor API for abstracting file systems; there's a reason we have gvfs and didn't wrap FUSE. See Alex's notes on this for more information. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
