Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
On Wed, 2011-05-11 at 11:55 +0100, Bastien Nocera wrote: On Wed, 2011-05-11 at 07:32 +0200, Michael Terry wrote: So as the Deja Dup maintainer, life will go on when you drop support. Worst case, I can just make the panel a dialog. But dropping the existing API feels like a frustrating bait and switch. It was not clear (at least to me) that this was your intentional all along, so myself and others made plans and put effort into making panels. Maybe next time you could whitelist the plugins you want or force people to compile with -DI_PROMISE_I_AM_BLUETOOTH so that 3rd parties don't waste time. I understand it's frustrating, but I don't remember anyone asking whether this API was considered stable, or anything of that kind. We have a couple of people working close to full time on the control-center, so those questions would certainly get answered. We thought that third-party developers would put some work into integrating their functionality within the control-center, instead, we were stumped when we saw the Input methods panel, which was a straight port from GNOME 2.x instead of something integrated in the Region Language panel. hmm, where's that Input methods panel code? We indeed want it go through design and integrated into the Region Language panel ___ 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 Re: GNOME Feature Proposal: Backup]
On Mon, 2011-05-16 at 11:31 +0200, Rodrigo Moya wrote: On Wed, 2011-05-11 at 11:55 +0100, Bastien Nocera wrote: On Wed, 2011-05-11 at 07:32 +0200, Michael Terry wrote: So as the Deja Dup maintainer, life will go on when you drop support. Worst case, I can just make the panel a dialog. But dropping the existing API feels like a frustrating bait and switch. It was not clear (at least to me) that this was your intentional all along, so myself and others made plans and put effort into making panels. Maybe next time you could whitelist the plugins you want or force people to compile with -DI_PROMISE_I_AM_BLUETOOTH so that 3rd parties don't waste time. I understand it's frustrating, but I don't remember anyone asking whether this API was considered stable, or anything of that kind. We have a couple of people working close to full time on the control-center, so those questions would certainly get answered. We thought that third-party developers would put some work into integrating their functionality within the control-center, instead, we were stumped when we saw the Input methods panel, which was a straight port from GNOME 2.x instead of something integrated in the Region Language panel. hmm, where's that Input methods panel code? We indeed want it go through design and integrated into the Region Language panel It was in the im-chooser-gnome3 package in Fedora 15, which has since been disabled. The source still lives in im-chooser upstream: https://fedorahosted.org/im-chooser/wiki/ImChooser Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: LightDM
On Sun, 2011-05-15 at 13:30 -0500, Brian Cameron wrote: Bastien: snip I'll repeat what I said in the past. Solaris developers will need to write some code at some point, or just give up. We can't stand around waiting for them to make a move when we want to better the functionality of GNOME as a Desktop. I have personally written committed over 100 patches to GDM since the 2.21 rewrite timeframe. Work I have done has improved GDM usability, XDMCP code, how GDM works when managing multiple displays at the same time, etc. Other Solaris developers have also helped, such as Halton Huo. This has bee time consuming since (as Jos pointed out), getting changes accepted into GDM can be very time consuming. So, developers working on Solaris have been supportive of the new GDM rewrite, I think. Your comment seems to be rather dismissive. I didn't mean writing code for GDM, but rather having a hand in shaping the underlying services, and making sure there's parity in what you implement for Solaris, and what will be implemented for Linux. Anyway, is there a real need or benefit to talk about Solaris GDM participation in a discussion about whether to accept LightDM as a module? If LightDM uses the same interfaces as GDM, then you're going to have problems whether we stick with GDM, or go with LightDM. So you'll have a problem either way. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature Proposal - Sushi
On Sun, 2011-05-15 at 21:50 +0200, Olav Vitters wrote: On Thu, May 12, 2011 at 11:15:02PM +0100, Allan Day wrote: Sounds like it should be both a new feature and a part of GNOME core. It would be great to be able to introduce it as a feature in 3.2. I've started a feature page here [1]. [1] https://live.gnome.org/ThreePointOne/Features/FilePreviewing I'd like some (design) feedback about this. First of all, I didn't read the emails fully so I might be asking things that have been explained.. :) 1. Evince is supposed to be a generic document viewer. Is there any overlap with Sushi? I would guess that Sushi should use evince libraries to implement viewing for such documents. 2. What about the file associations? You might want to easily view things, or actually work with the file (change it). How would this be handled? What would happen by default on a double click? Sushi doesn't handle double-click associations, it would only handle the preview shortcut. It's not meant to replace the full applications. There's 2 problems I'd like to see listed here, one is that Sushi should use the mime-types exported by the full viewers (such that the video or audio parts would use the same mime-types as Totem, same for evince), the second is that the look and feel should also be shared with those applications, to avoid clashing styles. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: First release of geocode-glib available
On Sun, 2011-05-15 at 12:44 +0300, Alberto Mardegan wrote: On 05/14/2011 11:24 PM, Bastien Nocera wrote: The fact that we have only one implementation means that we have one well maintained implementation. I don't think it's much of a problem. Do you have particular reasons why you think that supporting multiple backends is actually useful? Availability of up-to-date street data is heavily dependent on the provider. Your point being? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Settings downstream would reasonably want to add [was: long thread with no resolution]
Il giorno ven, 13/05/2011 alle 08.33 -0400, Matthias Clasen ha scritto: * system-config-printer: We decided to continue to use that instead of the GNOME 3 c-c one. s-c-p is a lot more complete and proven. Hmm; this is an example of the pick-and-match mindset that pits downstreams against upstreams. Can't we cooperate on making the printer panel good enough for everybody ? At least for home environments, I suppose a major lacking feature in current Print panel is the ability to activate/check the cups-avahi stuff (publish printers configured on $LOCALHOST - show printers shared by other $HOSTS - share/unshare a specific printer). Maybe an option to allow all users to cancel any print job could be interesting (I can't print 'cause cups hanged on my roommate job, but now she is at swimming pool) I suspect reprint policies and banner management are not suited for Print panel design and idea, so I hope system-config-printer will be not discontinued, for the sake of lazy data center admins who don't want to learn cups.conf syntax in order to set up a new printer :) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: LightDM
Hi, Matthias Clasen wrote: I've read over the entire thread again, and you've really lost me. This was a fairly civil thread, compared to many other discussions we've had. Perhaps that's part of the issue? Cheers, Dave. -- Dave Neary GNOME Foundation member dne...@gnome.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature Proposal - Sushi
On Mon, May 16, 2011 at 11:39:31AM +0100, Bastien Nocera wrote: On Sun, 2011-05-15 at 21:50 +0200, Olav Vitters wrote: 2. What about the file associations? You might want to easily view things, or actually work with the file (change it). How would this be handled? What would happen by default on a double click? Sushi doesn't handle double-click associations, it would only handle the preview shortcut. It's not meant to replace the full applications. Just wondering how this feature would look like within GNOME. So: - what would the UI be in Nautilus? (default action vs preview) - how would it integrate with e.g. alt-f2 run dialog? - should/will the functionality be exposed/implemented elsewhere? e.g. jumplists? zeitgeist integration? -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: release-team-lurkers: for people who can read and not respond
On Mon, 2011-05-16 at 13:37 +0200, Olav Vitters wrote: The release-team mailing list is intended for private discussions between release-team members. It should not be interesting as anything that is important, we'll either announce or bring to an appropriate mailing list. The release-team was not open for subscribing for 2 reasons: 1. We want to discuss things amongst ourselves, not immediately already have replies from non-release team members 2. We should take discussions to appropriate mailing lists; we don't want to create any need for anyone to be on this mailing list As we noticed that people still wanted to subscribe to the release-team list, we've setup a release-team-lurkers mailing list as a test. http://mail.gnome.org/mailman/listinfo/release-team-lurkers If you wanted to follow and can *refrain* from taking part in discussions, subscribe to above list and you'll get a copy of all release-team emails. The archives will remain at: http://mail.gnome.org/archives/release-team/ Note that release-team-lurkers is a test. We will remove the entire mailing list if we think it has a bad effect. You could also have made the mailing-list private, and subscribed gmane to it. That way the archives would be accessible to the majority without resorting to having to setup a new mailing-list. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: release-team-lurkers: for people who can read and not respond
On Mon, May 16, 2011 at 12:45:10PM +0100, Bastien Nocera wrote: Note that release-team-lurkers is a test. We will remove the entire mailing list if we think it has a bad effect. You could also have made the mailing-list private, and subscribed gmane to it. That way the archives would be accessible to the majority without resorting to having to setup a new mailing-list. This was the easiestnicest solution due to secur...@gnome.org. secur...@gnome.org should automatically go to all release-team subscribers To avoid any differences in receivers of security@ and release-team@, the security@ has been setup to automatically send it to everyone subscribed in release-team@. As security@ could be rather critical (in practice 99%+ of all emails are spam), I preferred keeping this distinction. Another benefit is that we can easily get rid of the lurkers list, and make clear that there is a difference between being a release-team member and following the release-team emails. Further, we cannot change release-team to private. People are allowed to email release-team and raise issues. We just don't want anyone other than release-team to respond. Maybe I should've stressed the last bit more... -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: release-team-lurkers: for people who can read and not respond
On Mon, 2011-05-16 at 13:56 +0200, Olav Vitters wrote: On Mon, May 16, 2011 at 12:45:10PM +0100, Bastien Nocera wrote: Note that release-team-lurkers is a test. We will remove the entire mailing list if we think it has a bad effect. You could also have made the mailing-list private, and subscribed gmane to it. That way the archives would be accessible to the majority without resorting to having to setup a new mailing-list. This was the easiestnicest solution due to secur...@gnome.org. secur...@gnome.org should automatically go to all release-team subscribers To avoid any differences in receivers of security@ and release-team@, the security@ has been setup to automatically send it to everyone subscribed in release-team@. As security@ could be rather critical (in practice 99%+ of all emails are spam), I preferred keeping this distinction. Another benefit is that we can easily get rid of the lurkers list, and make clear that there is a difference between being a release-team member and following the release-team emails. Further, we cannot change release-team to private. People are allowed to email release-team and raise issues. We just don't want anyone other than release-team to respond. Maybe I should've stressed the last bit more... All good points, thanks for going into details. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature Proposal - Sushi
On 13 May 2011, at 00:06, Luca Ferretti wrote: Other places where file previews could be useful are the future gnome-shell desktop (not sure what's current design/label for planned place holding recent and pinned stuff) and file chooser (only open or save too?). Also some specific place such as, for example, the list of current resources in Pitivi (audio and video files you loaded from disk and ready to be placed on timeline). Also, Evolution, for attachments. This is a *really* handy feature in Mail.app on the Mac. Cheeri, Calum. -- CALUM BENSON, Interaction Designer Oracle Corporation Ireland Ltd. mailto:calum.ben...@oracle.com Solaris Desktop Team http://blogs.sun.com/calum +353 1 819 9771 Any opinions are personal and not necessarily those of Oracle Corp. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature Proposal - Sushi
On 16 May 2011, at 12:18, Luca Ferretti wrote: Also, what about content handler/previewer? I remember this similar feature on mac os provides a dedicated API and policy allowing third parties to provide their own previewers (i.e. gimp should/could provide the plugin to allow previewing of xcf files) On that note, one of the most useful things about the OS X equivalent (QuickLook) is that it comes with plug-ins out of the box for third-party apps that you don't necessarily have installed. In particular, this makes it possible to view the content of most simple .doc, .ppt, .xls files etc. without ever having to install any office software (Microsoft's or otherwise). It would certainly be great to see that functionality in GNOME, as I'm sure a lot of people (like me) only ever really use Libre/OpenOffice to read the occasional annoying .doc attachment. Cheeri, Calum. -- CALUM BENSON, Interaction Designer Oracle Corporation Ireland Ltd. mailto:calum.ben...@oracle.com Solaris Desktop Team http://blogs.sun.com/calum +353 1 819 9771 Any opinions are personal and not necessarily those of Oracle Corp. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature Proposal - Sushi
On Mon, 2011-05-16 at 11:39 +0100, Bastien Nocera wrote: On Sun, 2011-05-15 at 21:50 +0200, Olav Vitters wrote: 1. Evince is supposed to be a generic document viewer. Is there any overlap with Sushi? I would guess that Sushi should use evince libraries to implement viewing for such documents. Yeah, it indeed already uses EvDocument and EvView to render PDF documents. 2. What about the file associations? You might want to easily view things, or actually work with the file (change it). How would this be handled? What would happen by default on a double click? Sushi doesn't handle double-click associations, it would only handle the preview shortcut. It's not meant to replace the full applications. Yes; Sushi would never register itself as default application for any file type. This means double clicking a file would never open Sushi - you need an explicit different operation to trigger it (in Nautilus right now it triggers when pressing the spacebar). There's 2 problems I'd like to see listed here, one is that Sushi should use the mime-types exported by the full viewers (such that the video or audio parts would use the same mime-types as Totem, same for evince), the second is that the look and feel should also be shared with those applications, to avoid clashing styles. Right now this is implemented for most of the viewers in git master: - for images we load at runtime the mimetypes supported by the GdkPixbuf loader - for PDF/PS/... documents we load at runtime the list of supported Evince backends - for audio and video I copy-pasted the mimetype list supported by Totem As for the look and feel, can you be more precise? Are you saying e.g. Sushi should not use a custom/dark theme if the application counterpart doesn't? The UI chrome for Sushi is *very* minimal - basically the only clickable elements are an OSD-toolbar that automatically fades out after no motion events are received in a timeout, and the close button, so it's hard to make it look like a full-fledged application (and it's not what the previewer is aiming for, too). Cheers, Cosimo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature Proposal - Sushi
Hi Olav, On Mon, 2011-05-16 at 13:44 +0200, Olav Vitters wrote: - what would the UI be in Nautilus? (default action vs preview) Right now it's activated with Spacebar. Sushi would never be a default action, but it has to be explicitly triggered (show me the preview vs. open this file). I also figure it will replace the mouse-hover-on-audio-file preview Nautilus currently implements. - how would it integrate with e.g. alt-f2 run dialog? Hmm, not sure I see a lot of room for integration here, as alt+f2 is mostly for running a command, which is orthogonal to the previewer... - should/will the functionality be exposed/implemented elsewhere? e.g. jumplists? zeitgeist integration? Yeah, as I said in another reply, it could definitely be useful to integrate it in the file chooser, and it also might be useful for Finding and Reminding (though I think it's really early to even think about this kind of integration, as e.g. FR itself is still in the early design phase). OTOH I'm not sure the Zeitgeist information exports is useful at all for Sushi; what kind of integration were you thinking here? Cheers, Cosimo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature Proposal - Sushi
On Mon, 2011-05-16 at 13:42 +0100, Calum Benson wrote: On 16 May 2011, at 12:18, Luca Ferretti wrote: Also, what about content handler/previewer? I remember this similar feature on mac os provides a dedicated API and policy allowing third parties to provide their own previewers (i.e. gimp should/could provide the plugin to allow previewing of xcf files) On that note, one of the most useful things about the OS X equivalent (QuickLook) is that it comes with plug-ins out of the box for third-party apps that you don't necessarily have installed. In particular, this makes it possible to view the content of most simple .doc, .ppt, .xls files etc. without ever having to install any office software (Microsoft's or otherwise). It would certainly be great to see that functionality in GNOME, as I'm sure a lot of people (like me) only ever really use Libre/OpenOffice to read the occasional annoying .doc attachment. [ Note that office documents (both OpenDocument and MSOffice formats) viewing is currently supported in Sushi by using unoconv(1) to convert them to a temporary PDF and using the Evince plugin to view them ] Yes, it's currently possible for 3rd-party applications to provide custom plugins, and they would basically be treated exactly in the same way as a built-in one. Though I'd ideally see plugins for the most commonly used formats all in the main tree (git master actually has a pretty complete viewer set now), and I'm not providing any kind of API warranty, at least for the time being. Cheers, Cosimo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature Proposal - Sushi
On Mon, May 16, 2011 at 09:42:41AM -0400, Cosimo Cecchi wrote: about this kind of integration, as e.g. FR itself is still in the early design phase). OTOH I'm not sure the Zeitgeist information exports is useful at all for Sushi; what kind of integration were you thinking here? I meant more the finding and reminding. So if we show files somewhere in GNOME shell or elsewhere, that you could perhaps easily have a preview of it. Note: no idea if anything I said is a good idea, just wondering what the thoughts are. -- Regards, Olav ___ 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, 2011-05-12 at 22:58 +0100, Sergey Udaltsov wrote: We're not dictating anything; we're just making an awesome OS, the way we envision, period. Wait a sec. It was said (here and on IRC) that g-c-c wants to include only polished panels to g-c-c. Only panels that gnome UI specialists are happy with. It is a form of dictate - or I do not know what dictate is. Or did I misunderstand some statements? In a way, even HIG itself is a dictate - a relatively weak form of it (but at least put into the document, which is the best thing about HIG!) ___ well, it's really a way of asking people interested in having stuff in g-c-c to cooperate with GNOME designers and developers. Apart from that, that's how every piece of GNOME software works: maintainers include what they are happy with, not everything anyone wants to add. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: First release of geocode-glib available
On Sat, 2011-05-14 at 21:24 +0100, Bastien Nocera wrote: On Wed, 2011-05-11 at 10:20 +0200, Ted Gould wrote: On Mon, 2011-05-09 at 16:52 +0100, Bastien Nocera wrote: This library should be used in place of Geoclue's D-Bus API for geocoding and reverse geocoding. Is this now deprecated in the Geoclue API? Pretty much, though I can hardly tell KDE people to start using a glib-ish library for that. I would expect them to come up with their own library in due time. When we have a working new-fangled geoclue to replace the current one, the API (and the old geoclue code) will most likely disappear of their own. Why do you think they'd do that rather than just work on GeoClue? It seems like there's an advantage to using an API that can have multiple providers. The API is generic enough to support multiple providers, it's just that there's currently only one implementation. The fact that we have only one implementation means that we have one well maintained implementation. I don't think it's much of a problem. Do you have particular reasons why you think that supporting multiple backends is actually useful? I don't have a specific use case, but I would guess that name providers vary widely based on location. My guess would be that Yahoo is pretty good in the US/Europe but there's a better local provider for India/China for instance. I have no information on that, it just seems to be pretty consistent for data like this. Which is one of the things that struck me as odd with a new library being created that didn't use the plugable interface already created. Is there a reason you didn't just make a well maintained GeoClue backend? --Ted signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature Proposal - Sushi
On Mon, 2011-05-16 at 09:51 -0400, Cosimo Cecchi wrote: On Mon, 2011-05-16 at 13:42 +0100, Calum Benson wrote: On 16 May 2011, at 12:18, Luca Ferretti wrote: Also, what about content handler/previewer? I remember this similar feature on mac os provides a dedicated API and policy allowing third parties to provide their own previewers (i.e. gimp should/could provide the plugin to allow previewing of xcf files) On that note, one of the most useful things about the OS X equivalent (QuickLook) is that it comes with plug-ins out of the box for third-party apps that you don't necessarily have installed. In particular, this makes it possible to view the content of most simple .doc, .ppt, .xls files etc. without ever having to install any office software (Microsoft's or otherwise). It would certainly be great to see that functionality in GNOME, as I'm sure a lot of people (like me) only ever really use Libre/OpenOffice to read the occasional annoying .doc attachment. [ Note that office documents (both OpenDocument and MSOffice formats) viewing is currently supported in Sushi by using unoconv(1) to convert them to a temporary PDF and using the Evince plugin to view them ] Yes, it's currently possible for 3rd-party applications to provide custom plugins, and they would basically be treated exactly in the same way as a built-in one. Though I'd ideally see plugins for the most commonly used formats all in the main tree (git master actually has a pretty complete viewer set now), and I'm not providing any kind of API warranty, at least for the time being. Speaking as someone who used to work for a fairly large ISV, a stable way to provide plugins would be nice. Of course, we should get all the common stuff built in, but we're not going to get all the vertical apps. I understand not wanting to lock yourself into an API early, but I think it's something you should keep on the radar. I don't know how your current plugin works, but it seems to me it could work the same way as our thumbnailers: install a script that takes an input file and creates a preview, in this case in any of a number of standard formats. Thanks, Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: LightDM
On Fri, 2011-05-13 at 17:41 -0400, Colin Walters wrote: On Fri, May 13, 2011 at 12:55 PM, Robert Ancell robert.anc...@gmail.com wrote: There have been problems for years and years and years. There is some point where you need to reconsider if that strategy is appropriate. So here's some actual data: https://bugzilla.gnome.org/buglist.cgi?cf_gnome_target=---;cf_gnome_version=---;query_format=advanced;emaillongdesc1=1;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;bug_status=NEEDINFO;bug_status=RESOLVED;bug_status=VERIFIED;email1=robert.ancell%40gmail.com;product=gdm;emailtype1=substring It looks like to your credit, you have submitted patches; some like https://bugzilla.gnome.org/show_bug.cgi?id=596831 have been accepted, others like https://bugzilla.gnome.org/show_bug.cgi?id=593996 discussed, considered, and rejected. The latter one is obsoleted now by the accounts service anyways. I'm not convinced by this data that GDM has been a problematic code base to work on. You're obviously free to create a new project; but on the basis above, I'd say you really didn't try very hard to make real changes in GDM before deciding to rewrite from scratch. ___ even though I don't have real data here, I must say that I know Robert has been working on GDM a lot of time, so this is not fair really. Also, AFAIK, most distributions carry an insane amount of patches in their GDM packages, so that seems to mean something (not sure what though, not an expert on login managers myself). So, maybe other considerations for rejecting LightDM might apply, but for sure Robert's attempts to work on GDM to fix issues there does not apply at all. cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature Proposal - Sushi
As for the look and feel, can you be more precise? Are you saying e.g. Sushi should not use a custom/dark theme if the application counterpart doesn't? The UI chrome for Sushi is *very* minimal - basically the only clickable elements are an OSD-toolbar that automatically fades out after no motion events are received in a timeout, and the close button, so it's hard to make it look like a full-fledged application (and it's not what the previewer is aiming for, too). It could be better if the UI matches the current shell theme. May be like the way authentication dialogues are displayed now [1] (I mean the window borders and background). This will help in creating a more unified experience for the entire OS. [1] https://live.gnome.org/GnomeShell/Design/Whiteboards/AuthorizationDialog?action=AttachFiledo=gettarget=user.png ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature Proposal - Sushi
On Mon, 2011-05-16 at 16:15 +0100, Justin Joseph wrote: As for the look and feel, can you be more precise? Are you saying e.g. Sushi should not use a custom/dark theme if the application counterpart doesn't? The UI chrome for Sushi is *very* minimal - basically the only clickable elements are an OSD-toolbar that automatically fades out after no motion events are received in a timeout, and the close button, so it's hard to make it look like a full-fledged application (and it's not what the previewer is aiming for, too). It could be better if the UI matches the current shell theme. May be like the way authentication dialogues are displayed now [1] (I mean the window borders and background). This will help in creating a more unified experience for the entire OS. The shell look is actually reserved to the shell and bits that are part of the system. So applications shouldn't use the shell theme, otherwise there's no way to differentiate them. I'll note that sushi should be using the normal (non-dark) variant of the theme when playing audio though. I'm sure the jury is still out on whether it should use the dark variant for office type documents. [1] https://live.gnome.org/GnomeShell/Design/Whiteboards/AuthorizationDialog?action=AttachFiledo=gettarget=user.png ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature Proposal - Sushi
On Mon, 2011-05-16 at 16:36 +0100, Bastien Nocera wrote: I'll note that sushi should be using the normal (non-dark) variant of the theme when playing audio though. I'm sure the jury is still out on whether it should use the dark variant for office type documents. Could you expand on why you think this is a good idea? Admittedly, I didn't discuss this at long with the design team, but it seems inconsistent to me to use a different theme depending on the mime type of the displayed file, given that the chrome is composed by three elements (background, toolbar and pseudo window-decorations). Right now Sushi uses a custom CSS to define the color scheme, but that's mostly a development placeholder while the dark theme shipped with newer gnome-themes-standard makes its way into mainstream packages. I think it should unconditionally use the dark theme when those are available (FWIW Quick Look seems to use a custom dark theme too). Cheers, Cosimo ___ 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 13/05/11 15:20, David Zeuthen wrote:
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
How is this implemented at the network level? Ah, I just found the footnote:
[1] : Emphasis on _experiment_ here.. for production use, maybe we
should use the IMAP client code from Evo instead of the simple
hand-rolled IMAP client that I put together in a couple of days. Then
again, I don't know.
More on this story later in this mail, but: out of interest, were you
aware that Telepathy already supports mail notifications on (off the top
of my head) Google Talk, Yahoo!, MSN and AIM?
http://telepathy.freedesktop.org/spec/Connection_Interface_Mail_Notification.html
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?
No, not really.
To check I'm not misunderstanding: you're proposing that Gabble
(Telepathy's XMPP backend), rather than using its XMPP library to open a
connection to the server, would call out to GOA, which would have its
own implementation of the XMPP session initiation, certificate checking,
authentication, etc. code; once the session is established, GOA would
hand back an FD which Gabble would have to assume was in the right state
to pick up right after the authentication step?
This doesn't sound like a good idea to me at all. Do you really want to
bake detailed knowledge of all these disparate protocols into GOA?
Surely it makes more sense to keep the generic IMAP and SMTP code in the
mail client, the XMPP code in the XMPP service—and by inevitable
extension, the AIM code in the AIM service, etc.?
File descriptor passing is cool and all, but I really don't think it's
appropriate here for (say) the XMPP connection. Establishing a session
is not actually trivial (and in the future it could get even less
trivial—for example, we might want to support BOSH
http://en.wikipedia.org/wiki/BOSH). But in any case, it's already been
implemented, with the necessary hooks to plug into GOA for the SASL
authentication step already in place. These hooks have been used to
integrate with GOA-esque services (including Bisho on MeeGo Netbook, and
libaccounts and signon, and of course Gnome-Keyring) without needing to
include knowledge of all N keyring implementations in all M
protocol-specific Telepathy backends.
For what it's worth, this is what the Telepathy D-Bus API for SASL looks
like:
http://telepathy.freedesktop.org/spec/Channel_Interface_SASL_Authentication.html.
From my brief research into the world of IMAP, I think something similar
could be done there too. So then GOA's Google backend would understand
the custom SASL mechanisms Google uses on various protocols, but would
not need any details of the protocols themselves.
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
If the user's connected to Google *anyway* for XMPP, it makes sense to
use the XMPP mail notifications, rather than maintaining a separate
connection. Ditto IMAP and Evolution. (Inevitably there will be services
where the IM protocol doesn't do mail notification: I guess Facebook is
a likely example here.)
Having some kind of commonality between the different sources of mail
notifications would be a big win for the Shell, of course. It would be
great for it not to have to care whether the notifications were
piggy-backing on an IM protocol, on an IMAP IDLE session, or anything else.
But: I think this would be best achieved by having Evolution, Telepathy,
etc. implement a common API the Shell can monitor (or push their
notifications into GOA, so the Shell can listen to that), rather than
moving non-authentication-related network protocol code into GOA.
- but it could also be that a provider
Re: language/locale selector [was: Re: Settings downstream would reasonably want to add]
On Mon, 16.05.11 13:23, Martin Pitt (martin.p...@ubuntu.com) wrote: Hello Lennart, Lennart Poettering [2011-05-16 1:06 +0200]: Next question: can you point me to some sources? (or alternatively some project name I could google for?) Would like to have a look on it, before I spend time on this. [1] has the backend code plus polkit files. But please NB that I wouldn't like to see this being perpetuated a lot longer. I'm not sure whether GNOME 3 already has a D-BUS backend for storing system-wide configurations, similar to the obsolete gconf-defaults-service. If so, it might make more sense to integrate it there instead of having a separate backend for this. Well, I think the different smaller system settings we want to make configurable, like the system locale, or the hostname or the timezone probably all need a tiny bit of intelligence on the server side, in order to ensure compat and provide change notification. So my approach would be to provide carefully mini-sevices for these things which we ship along systemd, which do PK and write sane config files like /etc/hostname and friends, and have no further complex over-arching infrastructure for that. In Ubuntu we already have a catch-all ubuntu-system-service package [2] which provides a backend for setting system-wide proxy and keyboard settings. These weren't accepted upstream back then, but perhaps with GNOME 3 we should make another attempt to get this functionality upstream and make it work for everyone else? If that's still not desired, then depending on the fate of the language selection bits the ls-dbus-backend bits might go into the upstream control-center D-BUS backend or ubuntu-system-service. I think proxy control probably belongs into NM. Keyboard stuff is complex. It's out of my focus for now. So I'll chicken out from it for now. On Fedora we have a service which always keeps console and X11 kbd settings in sync. I think this is needlessly complex though, and we could simplify this. Just not sure how precisely. Lennart -- Lennart Poettering - Red Hat, Inc. ___ 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]
On 16 May 2011 18:22, Lennart Poettering mzta...@0pointer.de wrote: conmann also does geoloc? Is there something it doesn't do? Sounds almost as crazy as systemd ;-) AFAIK (and I may be wrong), but that's part of its am I really online ping to connman.net, which acts as a captive portal detection. The response packet contains a continent, or something. Ross ___ 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 16/05/11 18:20, David Zeuthen wrote:
Hi,
On Mon, May 16, 2011 at 12:55 PM, Will Thompson
will.thomp...@collabora.co.uk wrote:
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?
No, not really.
That's fine and, sure, in retrospect probably easiest if GOA doesn't
get involved with XMPP. I was mostly thinking out loud. And I was just
under the impression that you actually asked for GOA to make things
easier here.
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…
http://telepathy.freedesktop.org/spec/Channel_Interface_SASL_Authentication.html
I don't think GOA needs to know about such interfaces at all - we just
hand you either the OAuth (or OAuth2) token and you can do this
yourself, yes?
… (thinking out loud) GOA could have a simple API for the degenerate
custom SASL mechanisms like X-GOOGLE-TOKEN where the client provides (a
hash of) the token when telling the server it's selected a mechanism,
and the server says yes or no:
property SupportedMechanisms: as
method GetToken(s: Mechanism) → s
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.
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?
I'm not sure this is really an optimization that is worth it - it
seems to really muddy the picture a lot and I can imagine a future
where we allow the user to choose what GMail labels to notify for -
not sure how this would work with XMPP.
Good point. In any case: it's there if we want Hotmail/Yahoo!/other
webmail notifications with relatively effort.
But: I think this would be best achieved by having Evolution, Telepathy,
etc. implement a common API the Shell can monitor (or push their
notifications into GOA, so the Shell can listen to that), rather than
moving non-authentication-related network protocol code into GOA.
Sure, ideally GOA would only be concerned about dishing out tokens and
not care about getting involved in the actual protocol used for each
service. And with Telepathy it looks like it could work well.
Yup: great.
But for Mail and Calendar I'm not so sure - so that's why I'm adding
very simple interfaces to GOA that the shell can use for mail
notifications and calendaring in 3.2 (As a side-effect, this gives you
Mail notifications and Shell calendaring functionality even when Evo
is not installed). Once we have a good story for Mail and Calendar in
place, we can easily move it there.
I'd actually forgotten I had my calendars configured in Evolution until
I saw the beautiful agenda panel in the shell. :)
Cheers,
--
Will
___
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]
On Mon, 16.05.11 18:44, Ross Burton (r...@burtonini.com) wrote: On 16 May 2011 18:22, Lennart Poettering mzta...@0pointer.de wrote: conmann also does geoloc? Is there something it doesn't do? Sounds almost as crazy as systemd ;-) AFAIK (and I may be wrong), but that's part of its am I really online ping to connman.net, which acts as a captive portal detection. The response packet contains a continent, or something. Oh my. Conmann phones home? This gets more and more interesting... Lennart -- Lennart Poettering - Red Hat, Inc. ___ 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]
On Mon, 2011-05-16 at 20:20 +0200, Lennart Poettering wrote: On Mon, 16.05.11 18:44, Ross Burton (r...@burtonini.com) wrote: On 16 May 2011 18:22, Lennart Poettering mzta...@0pointer.de wrote: conmann also does geoloc? Is there something it doesn't do? Sounds almost as crazy as systemd ;-) AFAIK (and I may be wrong), but that's part of its am I really online ping to connman.net, which acts as a captive portal detection. The response packet contains a continent, or something. Oh my. Conmann phones home? This gets more and more interesting... No, it's to check whether the internet is available. I believe NetworkManager does something similar, so that when you're connected to a hotel/pub Wi-Fi, all your online things don't say Hey, I'm online, give me web page and they all end up being login pages. ___ 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 easonably want to add]
On Monday, 16 May 2011 at 19:20, Lennart Poettering wrote: AFAIK (and I may be wrong), but that's part of its am I really online ping to connman.net, which acts as a captive portal detection. The response packet contains a continent, or something. Oh my. Conmann phones home? This gets more and more interesting... http://git.kernel.org/?p=network/connman/connman.git;a=blob;f=plugins/portal.c Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: LightDM
On 13 May 2011 21:33, Ray Strode halfl...@gmail.com wrote: Hi, On Fri, May 13, 2011 at 1:06 PM, Robert Ancell robert.anc...@gmail.com wrote: Note that LightDM is not lighter in features, but in architecture. And a different focus, right? GDM is firmly a GNOME project, designed to integrate and work well with GNOME. LightDM is designed with the idea of being more generic right? More generic in the parts that are common. In the parts that are GNOME specific, as differentiated as is required. But you said someone will need to volunteer to do the GNOME integration part, right? Yes, correct. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: LightDM
On 14 May 2011 00:19, Matthias Clasen matthias.cla...@gmail.com wrote: On Fri, May 13, 2011 at 12:55 PM, Robert Ancell robert.anc...@gmail.com wrote: I was not going to propose this project because I am sick of this sort of unprofessional response, especially from leaders in the community. It was the insistence of other leaders in the GNOME community that I did end up proposing and the continual complaints from users, sysadmins, customers, designers, and programmers about the login experience. So, you consider it an unprofessional response if we are not falling over our feet in adopting a from-scratch rewrite of a core component that has not even been field-tested in any release yet ? Compare to the approach that Canonical takes to new things like, say GNOME3.. I think you will see some similarities. Not at all. All I want is a fair review, based on good technical information and not being name-called or judged on assumptions about my motivations. Not being field-tested is a completely fair criticism, and something I can take away and reuse in a proposal for GNOME 3.4. As both a Canonical employee and Ubuntu developer I can tell you we constantly review all available free software for inclusion. While we do not always agree on every point we agree on a lot more than we disagree. I'm happy to continue to discuss this on another thread or privately if you want to. Anyway, you are already pissed off, so probably best to stop... My frustrations have certainly boiled over, but I will now resolve those through the appropriate channels. Apologies for the anger. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: LightDM
On 14 May 2011 14:38, Fernando Herrera fherr...@onirica.com wrote: Wops, I moved the conversation offlist. Getting back to d-d-l. On Fri, May 13, 2011 at 4:06 PM, Robert Ancell robert.anc...@gmail.com wrote: On 13 May 2011 15:56, Fernando Herrera fherr...@onirica.com wrote: What about starting AT applications like orca to use them to interact with the greater? Yes, that is probably the solution we will use in Ubuntu/Unity. So, how? I mean, currently I don't see anycode on lighDM for this. Are you going to solve that at the distro level using some kind of script that would start the greeter and then the required AT? This logic would need to be in the greeter - the LightDM daemon does not have any requirement to have a11y support that I can tell of. The current example greeters have the a11y support their toolkits have (not tested yet). ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: LightDM
On 14 May 2011 00:45, Florian Müllner fmuell...@gnome.org wrote: On Fri, 2011-05-13 at 14:59 +0200, Robert Ancell wrote: Why replace GDM? - LightDM is a cross-platform solution. Will KDE replace kdm with LightDM or drop its non-greeter code in favor of LightDM? Are there any interesting discussions in the other camp that you can point us to? I unfortunately have not focused on the KDE community for default usage yet, as this is not a community I am familiar enough with yet. The Kubuntu developers are considering if it is appropriate for them to use LightDM and they have plans to discuss this with upstream. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Travel assistance applications to attend Desktop Summit 2011
Hello All, The GNOME Foundation provides travel sponsorships to individuals who want to attend Desktop Summit and need financial assistance. We are happy to announce the Travel Committee is ready to receive applications for sponsorships to attend Desktop Summit 2011. This year, The Desktop Summit is being held in Humboldt University, in Berlin, Germany, from Saturday 6th August, until Friday 12th August. The instructions are detailed at http://live.gnome.org/Travel Please read them carefully. Deadline: May 31, 2011, 19:00 UTC. You can start sending in your applications now! Some extra comments: * Any information you send to the Travel Committee will be private. * Asking for sponsorship *does not* guarantee you will get sponsored. * A good application with good information will be processed fast. * If you need help with accommodation, you should state in your application that you need lodging, and leave the cost blank. The organization has taken care of booking hostels in advance. * Always choose the most economical option when possible. People who need travel sponsorship, should look for the best price (i.e. through a service like kayak.com). If the Travel Committee finds a cheaper price, that will be the price considered during the evaluation. * If you need assistance with either accommodation or airfare, but not both, this year the Travel Committee will give higher priority to people requesting accommodation. * If your country needs a VISA invitation letter and you are a GNOME contributor, please let the GNOME Travel committee know about it. * If you are selected for the Google Summer of Code or the GNOME Outreach Program for Women (as student or mentor) you should mention it in your application. * If your talk was selected for the Desktop Summit, you should mention it in your application. * The Travel committee should reply back about receiving your application within 2-3 days. After that we would accumulate all the sponsorship requests and process them together. So please do not panic (have any butterflies in your stomach) if we take some time to reply on the status. Affirmative/Negative you would surely get a response. * No personal emails to committee members. Please keep travel-committee Cc'ed on all your replies. Feel free to ask questions on the travel-committee list. You can also find us in the #travel channel at irc.gnome.org Regards, Bharath On Behalf of GNOME Travel Committee ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
