Re: 3.6 Feature: Initial setup
On Mon, 2012-04-23 at 14:08 -0400, Matthias Clasen wrote: Sure, I agree that the online account and intro tour steps are useful for every new user, not just the first. Beyond that, they are also useful for an existing user who just upgraded his system from GNOME 2 and is not familiar with the new features of GNOME 3. I'm confident that we can find a way to provide the same UI in these situations. The main focus of the feature as it is written now, is certainly the single-user machine - since that is a really common case (...not going to make up numbers). Didn't we intentionally ditch the startup wizard from GNOME 2.early something on the theory that we should just let users use their computer and all of our functionality should be easily discoverable? I sort of like the idea of a totally fresh GNOME session starting up with a Web and www.gnome.org/welcome/ in the browser, with lots of little YouTube videos. That could be useful and unobtrusive. --danni -- Danielle Madeley Senior Software Engineer, Collabora Ltd. www.collabora.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Anyone interested in keeping pessulus alive?
On Mon, 2012-03-12 at 08:51 -0700, Sriram Ramkrishna wrote: Pessulus was a configuration lockdown editor for GNOME 2. It never got ported to GNOME 3, as it more or less involves a complete rewrite (move to introspection-based bindings and move to GSettings) and nobody found the motivation to do so. Oh, that is just too bad. I would think that this would be useful in large installations. I hope someone take up the challenge to port it. Potential summer of code project? -- Danielle Madeley Software Developer, Collabora Ltd. Melbourne, Australia www.collabora.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Anyone using UNCONFIRMED in Bugzilla?
On Tue, 2012-01-03 at 16:39 +0100, Olav Vitters wrote: On Tue, Jan 03, 2012 at 10:55:15AM +1100, Danielle Madeley wrote: +1 here. I've already decided it is going to be optional per product. Whomever can edit the product (=marked as developers) will be able to kill the UNCONFIRMED for that product. I actually prefer the idea of NEW/CONFIRMED as statuses. Most people won't appreciate the difference between NEW and UNCONFIRMED. I'd mostly like to use the CONFIRMED status for long running bugs so we can say yes, we know about this, it's just really hard. --danni -- Danielle Madeley Software Developer, Collabora Ltd. Melbourne, Australia www.collabora.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Anyone using UNCONFIRMED in Bugzilla?
On Tue, 2011-12-27 at 17:16 +, Philip Withnall wrote: I'd like to see UNCONFIRMED removed but maybe as a compromise add a confirmed Bugzilla keyword for projects to use or not use as they please. That's a very reasonable suggestion which I think would work. +1 here. -- Danielle Madeley Software Developer, Collabora Ltd. Melbourne, Australia www.collabora.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dynamic help menus for 3.2
That actually works as well in my prototypes, but it might not be in good enough shape for 3.4. The interaction with a text entry in a menu is really hard in GTK+. GtkMenu just wasn't designed to do that. Could it be made to work only with GtkAction/GtkUIManager? -- Danielle Madeley Software Developer, Collabora Ltd. Melbourne, Australia www.collabora.co.uk ___ 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 Wed, 2011-05-11 at 11:47 +0100, Bastien Nocera wrote: On Wed, 2011-05-11 at 11:02 +1000, Danielle Madeley wrote: On Wed, 2011-05-11 at 01:27 +0100, Bastien Nocera wrote: #1 -- was this announced/proposed to desktop-devel-list? No, because it was only made for one particular module (gnome-bluetooth), and by me. The reason we had an external API was so that gnome-bluetooth code happen in time for 3.0. And we've reverting it to 3.2. Empathy has some control-center shell integration as well for its accounts configuration. Or perhaps it's an old version of the API. It was primarily done for Meego Netbook. That will hopefully be superseded by the Web Accounts panel David is working on. The last I heard, David's design was only for unifying, single-sign-on accounts such as Facebook and Google. Things that were pure IM accounts would still be in a separate capplet. -- Danielle Madeley Software Developer, Collabora Ltd. Melbourne, Australia www.collabora.co.uk ___ 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 Wed, 2011-05-11 at 01:27 +0100, Bastien Nocera wrote: #1 -- was this announced/proposed to desktop-devel-list? No, because it was only made for one particular module (gnome-bluetooth), and by me. The reason we had an external API was so that gnome-bluetooth code happen in time for 3.0. And we've reverting it to 3.2. Empathy has some control-center shell integration as well for its accounts configuration. Or perhaps it's an old version of the API. It was primarily done for Meego Netbook. ~ Although I endorse design of the core components, I don't think it has to require the component to exist in gnome-cc. Furthermore, this seems like a fairly arbitrary limitation. Both major non-free desktops permit applications to install control-center. -- Danielle Madeley Software Developer, Collabora Ltd. Melbourne, Australia www.collabora.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Musings on the contacts user experience
On Fri, 2011-04-29 at 17:05 +0200, Guillaume Desmottes wrote: Not really, we could easily imagine being online without having Empathy running without having a people tab: user will just have to start Empathy to see his contact list. If we don't allow that atm, it's mainly because: A) The Shell presence doesn't have a 'Offline' mode or at least a way to properly integrate IM and desktop presence at the same time. Am I the only one who thinks this is simple as: Go Online for Chat and Calls [ Off | On ] in the bottom of the presence menu? B) Some things (such as muc invitations, incoming file transfer) still require the 'empathy' process to be running. I am strongly looking forward to decoupling the empathy process from changing account presences when it goes on/offline. --danni -- Danielle Madeley Software Developer, Collabora Ltd. Melbourne, Australia www.collabora.co.uk ___ 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, 2011-04-19 at 09:08 -0400, David Zeuthen wrote: 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. This is very doable. On Meego Netbook we wrote a Telepathy Mission Control plugin that got the accounts from libsocialweb. Within Empathy's accounts capplet it then showed the Facebook account name, an enable/disable toggle (which was also shown in Web Accounts) and a button that launched the Web Accounts editor. There is also a different SSO plugin for Meego Handset. I mention the former one because it was specifically designed for the desktop and to integrate with Empathy. ~ The Web Accounts dialog on Meego is called 'bisho'. It's pluggable, allowing the provision for extra authentication mechanisms (e.g. for Facebook we required both the OAuth2 token AND a legacy Facebook Connect token *). * Tokens are stored in the keyring. -- Danielle Madeley Software Developer, Collabora Ltd. Melbourne, Australia www.collabora.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: empathy integration with the desktop
On Wed, 2011-03-30 at 14:06 +0200, Alexander Larsson wrote: Yes, I'm not talking about how telepathy works here. I'm talking about designing the user experience of chat integrated with gnome-shell. I have little knowledge about how empathy/telepathy really works, and I've not really used it much before. So, as a native user, my view of the current status is that: * You can setup accounts easy in the global settings dialog * Once online you can change status easily in the menu and you get nice messages in the message tray when someone IMs you. However, In order for it to work you need to launch the empathy app manually. So, what I proposed was to have the shell spawn empathy to make this work. But, if we can do that without starting empathy that is even better. Still, the initial problem stands, as we're not currently doing this. I appreciate what you're saying about how the user sees things, but it seems that developers are also consistently confused about how things work. The point of my email was to clarify things for developers so they can create the user experience they desire. So, we need to modify the shell somehow to make it possible to use the telepathy integration without having to manually start empathy. My proposal would be to put an offline item in the user menu. I support this idea. -- Danielle Madeley Software Developer, Collabora Ltd. Melbourne, Australia www.collabora.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: empathy integration with the desktop
It's very important here to distinguish between Telepathy as a service and Empathy which is providing the views of that service. If the shell wants to sign the Telepathy accounts in, it's quite easy to do that, it just needs to make the appropriate D-Bus call and it will happen. Once the accounts are signed in, appropriate components (i.e. the shell's text handler or Empathy) will be launched in response to requested/incoming channels. So if you want to go online automatically, simply design what that will look like in the user interface and make it signal mission control that you wish to go online. On Tue, 2011-03-29 at 10:09 +0200, Alexander Larsson wrote: In order to go online and have the integrated stuff work in the background you must first start a weirdly named application (Empathy) and then close(!) its window (this will not actually quit the app). This causes you to go online and start using the integrated messaging systems. The app is a view. We could make it quit the app. We could also make it not automatically put you offline (which it does at the moment when you quit). Really the only reason not to quit the app is to save having to load all that state again next time you want the roster (chat and video calls are in separate processes). Once again, the communications itself are a desktop service and separate to the app. We could automatically launch empathy by default on login, but people might not like to automatically go online as soon as they are at the computer. To reiterate, not actually required. Just talk to mission control. Mission control will launch UI components on demand for requested/incoming channels. Summary: Telepathy is a communications service, Empathy is a view of that service. It's like how you don't have to launch nautilus to carry out file operations. -- Danielle Madeley Software Developer, Collabora Ltd. Melbourne, Australia www.collabora.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Git: Do not use http to access Git!
On Thu, 2011-02-17 at 10:48 +0100, Olav Vitters wrote: Some people have been using the cgit interface to checkout a lot of git modules. This cause a very high load on our server. Please use the git protocol instead. For now I've blocked git from accessing cgit as too many people have been using the http interface and it negatively impacts performance (very high loads over long periods). Is it possible these people are on ridiculous corporate networks that only permit HTTP traffic (via a proxy) and allow no other outgoing connections beyond their network? I have been on one of these before, http was the only way I could checkout sources (from Subversion at the time). If this is the case, git being awesome as it is, perhaps someone could set up a remote that offers http cloning that updates once a day or so. This would let people clone a repo, and still submit their work via format-patch etc. --danni -- Danielle Madeley Software Developer, Collabora Ltd. Melbourne, Australia www.collabora.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Maintainers, please read: 2.31.92 fun
On Wed, 2010-09-15 at 12:47 +0200, Vincent Untz wrote: - telepathy-glib: Namespace conflict for 'iface_quark_connection_manager'. I think that's something that should get fixed in g-i? What tp-glib are you building? This should be fixed since 0.11.15. -- Danielle Madeley Software Developer, Collabora Ltd. Melbourne, Australia www.collabora.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: desktop schemas review [was: Re: GSettings migration status]
On Sun, 2010-07-04 at 00:10 +0100, James Sharpe wrote: Might I suggest that you take the opportunity at this point to extend the schema to at least consider support for multiple desktops / monitors. One of the difficulties that I found when looking at this in GSOC a few years back was that there was no way of supporting use of schemas when you had a dynamic number of items that needed the same configuration (e.g. background/screen0, background/screen1 etc), If this functionality is still not available with GSettings shouldn't it be put on the list of things to be addressed for the future? There are two ways of doing this I can see. Using the same schema with multiple paths or making the keys dictionaries. -- Danielle Madeley Software Developer, Collabora Ltd. Melbourne, Australia www.collabora.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Empathy is now using GSettings
For anyone building Empathy master. I've just merged the branch that ports Empathy to GSettings. You're gonna require GLib 2.25.9. I'm now happily using it with the DConf 0.4 backend. If you don't have DConf, it won't save your preferences between instances, you have been warned. There is a .convert file for gsettings-data-convert that should ideally convert your GConf preferences into DConf prefs. This is a fairly direct port, that doesn't really take advantage of things like g_settings_bind() yet. Be aware though there is no more EmpathyConf, any outstanding branches that call into EmpathyConf need to be ported to pure GSettings. Some information is available in https://bugzilla.gnome.org/show_bug.cgi?id=616362 File bugs in GNOME Bugzilla under Empathy. Thanks, --danni -- Danielle Madeley Software Developer, Collabora Ltd. Melbourne, Australia www.collabora.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
On Fri, 2010-06-11 at 18:36 +0200, Xavier Claessens wrote: Le 10/06/10 13:27, Richard Hughes a écrit : On 10 June 2010 12:24, Andre Klapperak...@gmx.net wrote: This requires module maintainers to port their modules now (if you don't want an angry release-team mob soon in front of your house). So, should we be requesting gtk3= 2.90 in configure.ac now? At least for Fedora rawhide the lack of gtk-engines makes all the gtk3-using application look fugly. To make Empathy build with gtk3 we need: - libcanberra-gtk-3 - libchamplain-gtk-3 - libclutter-gtk-3 - libunique-3 (or drop gtk2 compatibility and use GtkApplication) I think we should just port to GtkApplication. I've filed: https://bugzilla.gnome.org/show_bug.cgi?id=621339 It would be nice if GtkApplication was also available in GTK+ 2.21.x though, it would ease the porting effort. - libwebkit-3 Once they are all released and parallel installable (we would like to not lose gtk2 compatibility), we are ready to make the move :-) Regards, Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Danielle Madeley Software Developer, Collabora Ltd. Melbourne, Australia www.collabora.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New external dependencies for 2.32: telepathy-logger
On Fri, 2010-03-19 at 16:01 +0100, Guillaume Desmottes wrote: Le vendredi 19 mars 2010 à 11:39 -0300, Jonh Wendell a écrit : I know we have gains, but we also have cons, with the desktop full of processes. Perhaps we should only activate the daemon when needed by some application, and deactivate it when the application closes? That's almost already the case here. The tp-logger daemon is automatically launched when first conversation is started. It's currently not automatically stopped but I just talked to the tp-logger developers and they will consider stopping it after some time of inactivity. The daemon could be shut down if there are no channels to log, I'm not sure if it's worth it though. Unused pages will be swapped out, and the daemon should remain quite asleep as long as there is no Telepathy activity (it wakes up once an hour to do some maintenance). Plus, this functionality is already resident in Empathy, really we're just moving the code to another place. -- Danielle Madeley Software Developer, Collabora Ltd. Melbourne, Australia www.collabora.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Platform for Developer Documentation
On Mon, 2010-03-08 at 09:57 +0100, Tomeu Vizoso wrote: Have you considered talking a bit about coarser components such as abiwidget, evince, vte, webkit/gtk+, tinymail-ui, gtksourceview, empathy-gtk, etc? There is no libempathy-* any longer. All programming should be done with telepathy-glib directly. Though in the future there will also be a telepathy-gtk. -- Danielle Madeley Software Developer, Collabora Ltd. Melbourne, Australia www.collabora.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: External Dependency Proposal: libappindicator
On Fri, 2010-02-19 at 22:54 -0600, Ted Gould wrote: It would be much cleaner to either expose the underlying dbus api or proxy something that is explicitly designed with this in mind: GtkActions. That's a great idea. What do you think would be a good API/name for a function that did that? Do you think it should take an array of actions or some sort of root action? Do you think that the function that takes a GtkMenu * should be deprecated? It seems to me that it should probably take a GtkUIManager path. It can then serialise the menu description and association GtkActions over the bus to be recreated on the other side. Applications creating their menus directly and not using GtkUIManager should probably be ported anyway. I would remove any API that takes a GtkMenu directly, since this is a GtkWidget and really cannot be reliably proxied over D-Bus (what would happen if I tried to poke in some of the widget properties of that GtkMenu?). --danni -- Danielle Madeley Software Developer, Collabora Ltd. Melbourne, Australia www.collabora.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Branch notifications
On Wed, 2009-11-25 at 17:27 -0300, Germán Póo-Caamaño wrote: On Thu, 2009-11-26 at 07:03 +1100, Danielle Madeley wrote: On Wed, 2009-11-25 at 13:03 -0600, Shaun McCance wrote: The only potential problem is that the emails come from your username @src.gnome.org. I know sha...@gnome.org gets to my inbox, and I think sha...@src.gnome.org does as well. But do we have proper aliases set up for everybody who has git access? Could you simply use the email in the commit instead? I think Shaun refers to that email. Can we assume then that that email will work, since they've chosen it. -- Danielle Madeley Software Developer, Collabora Ltd. Melbourne, Australia www.collabora.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Branch notifications
On Wed, 2009-11-25 at 14:26 -0600, Shaun McCance wrote: On Thu, 2009-11-26 at 07:03 +1100, Danielle Madeley wrote: On Wed, 2009-11-25 at 13:03 -0600, Shaun McCance wrote: The only potential problem is that the emails come from your username @src.gnome.org. I know sha...@gnome.org gets to my inbox, and I think sha...@src.gnome.org does as well. But do we have proper aliases set up for everybody who has git access? Could you simply use the email in the commit instead? No, I don't think that will work, because branches in git don't result in new commits. Ok, actually, that's a very good point. -- Danielle Madeley Software Developer, Collabora Ltd. Melbourne, Australia www.collabora.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Danger: older bugs are getting squashed with NEEDINFO
On Fri, 2009-09-18 at 14:28 -0400, Owen Taylor wrote: I think for most modules, confirming bugs has usually seemed like a waste of of the maintainer's time. Confirming bugs assumes that the maintainer isn't looking at bugs until they are confirmed. Once the maintainer is already looking at a bug, what's the point of confirming it? So, while it is indeed an extra click or two to confirm a bug as NEW, is it really that much extra time? Surely most of your time was spent in reading the bug, thinking about it, establishing that it was not a duplicate, and then commenting on it that confirming it is only one extra mouse click. It seems that an UNCONFIRMED bug is likely to move into one of three states: NEW, DUPLICATE or NEEDINFO. Sometimes if the fix is easy, you might fix it immediately and move it to RESOLVED, but in this case the 1yr rule clearly does not apply. Marking bugs also seems to me to be a polite way of telling the reporter that you're aware of her issue and that it does seem to be a legitimate bug (especially in the case of GTK+ or another library, this means that maybe the reporter will stop trying to work out if it's a bug in her code). I know that sometimes you can't be sure about a bug immediately, so you leave it alone. Maybe we need a system that finds all UNCONFIRMED bugs that are 6 months old, or 11 months old and emails a reminder summary to the maintainer. That gives the maintainer an opportunity to confirm the bugs she now knows/suspects to be real. --danni -- Danielle Madeley Collabora Ltd., Melbourne, Australia http://www.collabora.co.uk/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
