Re: Commit auto-links in bugzilla comments
Le mardi 10 février 2015 à 08:38 +0100, Milan Crha a écrit : Hello, I'd like to ask: how does the auto-links for commits in the new bugzilla work? I mean, if I write something like: commit abcde12345 then the abcde12345 will become a link to the sources in the product the current bug is filled for. It works similarly to bug auto-link references, which is nice. Related to this, I've proposed to also link branch wip/... in this bug: https://bugzilla.gnome.org/show_bug.cgi?id=744068 My problem is when one change for a product A requires also a change in product B and I reference commits for both products within one bug report. That may cause one of the commit links invalid. Is there a way to tell the comment parser that the commit itself belongs to another product than the one the bug is filled for? If we come with a way to specify the module, would be nice to adapt my patch likewise :) Regards, Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Commit auto-links in bugzilla comments
Le mardi 10 février 2015 à 08:38 +0100, Milan Crha a écrit : Hello, I'd like to ask: how does the auto-links for commits in the new bugzilla work? I mean, if I write something like: commit abcde12345 then the abcde12345 will become a link to the sources in the product the current bug is filled for. It works similarly to bug auto-link references, which is nice. Related to this, I've proposed to also link branch wip/... in this bug: https://bugzilla.gnome.org/show_bug.cgi?id=744068 My problem is when one change for a product A requires also a change in product B and I reference commits for both products within one bug report. That may cause one of the commit links invalid. Is there a way to tell the comment parser that the commit itself belongs to another product than the one the bug is filled for? If we come with a way to specify the module, would be nice to adapt my patch likewise :) Regards, Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Commit auto-links in bugzilla comments
Le mercredi 11 février 2015 à 09:52 -0800, Jasper St. Pierre a écrit : Out of curiosity, is there anything wrong with just copy/pasting a link? You know, something like https://git.gnome.org/browse/gnome-shell/commit/?id=d54b87c4559bd9d74fa10d3e3d1e38a933bea051 There is nothing wrong with copy/pasting the link, but then you have to browse git.gnome.org to find the commit/branch link. The nice thing with letting bugzilla build the link is that all you need to know is the commit hash or branch name, and that info is in your terminal. I find that trying to remember crazy syntax and exceptions is a bit difficult. Does it work inside parens with immediate closing like (see also comment #13)? Does it work with and without the number sign? After a line-break, one like Bugzilla likes to auto-add? I've ran into so many exceptions it's hard to remember what's valid. It's indeed hidden secret, and the regex isn't always perfect the first time. Nobody is forced to use it, but IMO it's nice little trick that doesn't cost us much, does it? On Wed, Feb 11, 2015 at 9:43 AM, Xavier Claessens xclae...@gmail.com wrote: Le mardi 10 février 2015 à 08:38 +0100, Milan Crha a écrit : Hello, I'd like to ask: how does the auto-links for commits in the new bugzilla work? I mean, if I write something like: commit abcde12345 then the abcde12345 will become a link to the sources in the product the current bug is filled for. It works similarly to bug auto-link references, which is nice. Related to this, I've proposed to also link branch wip/... in this bug: https://bugzilla.gnome.org/show_bug.cgi?id=744068 My problem is when one change for a product A requires also a change in product B and I reference commits for both products within one bug report. That may cause one of the commit links invalid. Is there a way to tell the comment parser that the commit itself belongs to another product than the one the bug is filled for? If we come with a way to specify the module, would be nice to adapt my patch likewise :) Regards, Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Jasper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
Hello, Any plan to add a suspend menu entry, or should we still use the undiscoverable 'alt' trick? Newer GNOME version (3.6 ?) fixed the problem of not being able to shutdown with another problem of not being able to suspend, that's not an improvement... Or did I miss something? Sorry if that was already discussed in the thread, I rekon I did not read everything. Regards, Xavier Claessens. Le lundi 22 avril 2013 à 14:36 +0100, Allan Day a écrit : Hi all, This is something that me, Jon and Jakub have been thinking about for some time, and is now at the stage where we can start to think about implementation. I'm proposing it as a feature for 3.10 [1]. The main element of the design is to combine the sound, network, bluetooth, power and user menus into a single menu. This will enable us to resolve a number of UX issues we've encountered with the existing design (badness on touch, difficulties having the user name in the top bar, lots of complexity in some menus, like network, virtually none in others, like sound...). It will also give us greater flexibility, and will allow us to deal with some features - like airplane mode - in a more elegant and discoverable manner. More details are outlined on the wiki [2]. If you do look at the designs, please pay particular attention to the example scenarios - these give a clearer idea of what the menu will actually look like. The designs aren't finalised yet, so comments and ideas are welcome. It should be said that, as with any design, there are tradeoffs here. There are lots of advantages to this approach (see the design page), but there are one or two actions that might require an extra click with the new design. The primary example of this is switching wifi networks: with the new design, this will require that you open the system menu, click on the wi-fi entry, and then choose the network you want from the control center panel (as opposed to just selecting the network from the menu itself). However, while switching wi-fi networks will require an extra step, I actually think that the the experience will be better with the new design. The current network menu contains a lot of information that isn't related to wi-fi, and isn't exactly straightforward to use - in many respects, the new design will be more straightforward to use, even if there is an extra click involved. Also, we are planning a new wi-fi selection dialog, which should be a big improvement in those situations where you are not already connected to a network. Allan [1] https://live.gnome.org/ThreePointNine/Features/SystemStatusMenu [2] https://live.gnome.org/GnomeShell/Design/Guidelines/SystemStatus/#Update_Proposal -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
ctr-del to delete a file
Hello ddl, Looks like it is time to start flames on ddl, so let's start a new one: W-T-F is that ctr-del to move a file to trash in nautilus?? And there is not even an indication why pressing del does nothing! To add even more fun, it is not even consistent with evolution to delete emails. So I got used to nautilus, and now I often tap ctr-del in evolution and that does nothing. PLEASE REVERT THIS ASAP! Regards, Xavier Claessens. PS: https://bugzilla.gnome.org/show_bug.cgi?id=648658 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ctr-del to delete a file
Le jeudi 19 mai 2011 à 08:16 -0700, Xan Lopez a écrit : On Thu, May 19, 2011 at 8:07 AM, Xavier Claessens xclae...@gmail.com wrote: Hello ddl, Looks like it is time to start flames on ddl, so let's start a new one: No, it's not. Please do not spam the list with your pet peeve bugs. Especially when there's already a bug filed in bugzilla, which is the right forum to discuss these issues. The bug is just being ignored. I think more visibility is needed to get that wrong behaviour reverted. Regards, Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ctr-del to delete a file
Le jeudi 19 mai 2011 à 11:54 -0400, Cosimo Cecchi a écrit : Hey Xavier, this is not going to be reverted in 3.0.x. Note that you can still change this manually back to Del, as Nautilus still supports editable accels (even though there's a bug [1], which I want to fix for 3.0.2, if you do that). Why can't this be reverted for 3.0.x? I understand a proper solution can't be made before 3.2, that's why I'm asking to revert the ctr-del behavior for now. I don't really care changing the accels for myself, I know it is ctr-del. I'm just astonished that this change as been made in the last minute in GNOME3 with apparently no consensus and no indication to users. Users can only assume GNOME3 can't delete files, ctr-del is impossible to discover without reading bugzilla. We might reconsider this choice in 3.2, once Undo support has hopefully landed, but in the meanwhile I find it really impolite you're screaming out loud here, as you surely know there are more appropriate channels to reach the Nautilus maintainers. Starting flames is not cool. So you change a 10 years old behavior, you wait 6months for people to learn it the hard way, then will change it again? Don't you think users could have waited 6 more months to have directly the proper solution? Regards, Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ctr-del to delete a file
Le jeudi 19 mai 2011 à 16:00 -0400, Colin Walters a écrit : On Thu, May 19, 2011 at 3:50 PM, Xavier Claessens xclae...@gmail.com wrote: Users can only assume GNOME3 can't delete files, ctr-del is impossible to discover without reading bugzilla. It's listed quite clearly in the Edit...Move To Trash menuitem. Do you seriously use that menu? Do you seriously think users will see that there? if it was in the context menu, ok... but there, sorry but no. So you change a 10 years old behavior, you wait 6months for people to learn it the hard way, then will change it again? Don't you think users could have waited 6 more months to have directly the proper solution? Not sure if you noticed but there were a few other changes from GNOME 2.x to GNOME 3.0 =) Can we calm down? A decision was made for 3.0, it makes sense to stick to it; there's an improvement planned for 3.2. I rather see this as a bug was introduced in 3.0 and should be fixed in 3.0.2. Regards, Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.0 in March 2011
Le 29/07/10 09:56, Bastien Nocera a écrit : On Thu, 2010-07-29 at 09:24 +0200, Frederic Peters wrote: Paolo Borelli wrote: I still would like to have a definitive description of what 2.32 apps can and cannot use: for instance will the new glib be part of the release (and hence gsettings etc)? There will be both a glib and a GTK+ 2.x release in September; modules should still be ported to use GSettings, hopefully a GtkApplication backport will land soon in GTK+ and module are encouraged to use it. Also the GTK+ 3 migrating story (get your module building with gseal, without using deprecated parts, and it will work) should still hold true; there was a GTK+ meeting yesterday, probably they will send minutes and a detailed status update. In the specific case of gedit, there's the issue of libpeas, it is really your call if you want to start using it already in 2.32. Given that apps that wanted to port to GSettings are already ported, I really don't see why we're advising to use GTK+ 2.x/3.x selection at configure-time when we've been telling people to target GTK+ 3.x. IMO the big mistake here is to have accepted modules to drop GTK2 compatibility. I told the RT to make clear that modules must keep that compatibility, but they are only realizing it now... I think we should now remember: NEVER DEPEND ON GTK VERSION THAT ARE NOT RELEASED EARLY IN GNOME SCHEDULE!!! We already had that issue in the past, and we did the same mistake again. Speaking about my modules, I will not accept any changes to make them work with GTK+ 2.x again, nor would I want people to waste their times doing that. Why? As I understand, GTK3's only advantage is to have GtkApplication, which is being backported to 2.22, right? So I don't see why you can't make a --enable-gtk3 switch in your modules. Empathy is doing that from the beginning, and it works fine. The 2.32 story is inexistent: Hey, you have a couple of weeks to release something that you didn't plan for, and that didn't exist. If I understood, the story for 2.32 is the same than what we planned to be 3.0 so far. Except: 1) modules should release with the version '2.32' instead of '3.0'. 2) gnome-shell won't be part of that release 3) modules must build with GTK 2.22, with extra bonus if they also build with 3.0. 4) did I forgot something else? Regards, Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.0 in March 2011
Le 29/07/10 13:50, Steve Frécinaux a écrit : On 07/29/2010 01:06 PM, Xavier Claessens wrote: Speaking about my modules, I will not accept any changes to make them work with GTK+ 2.x again, nor would I want people to waste their times doing that. Why? As I understand, GTK3's only advantage is to have GtkApplication, which is being backported to 2.22, right? So I don't see why you can't make a --enable-gtk3 switch in your modules. Empathy is doing that from the beginning, and it works fine. This is not so easy for some modules. Especially, those who rely on bindings and have been working toward gobject-introspection support (as gedit, totem and vinagre did, by supporting libpeas) must deal with the fact that those new bindings (or at least, pygobject's g-i support, which was the concern in gedit's case) won't see a 2.32 release. The 2.32 story is inexistent: Hey, you have a couple of weeks to release something that you didn't plan for, and that didn't exist. If I understood, the story for 2.32 is the same than what we planned to be 3.0 so far. Except: 1) modules should release with the version '2.32' instead of '3.0'. 2) gnome-shell won't be part of that release 3) modules must build with GTK 2.22, with extra bonus if they also build with 3.0. 4) did I forgot something else? - pygobject with g-i support won't be part of that release Right, that's indeed a bigger issue I didn't though about. - dconf won't be part of that release Really? So what will happens for apps that are already ported to GSettings, like Empathy? Regards, Xavier Claessens. ___ 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
Le 13/06/10 04:36, Michael Terry a écrit : On 12 June 2010 11:31, Xavier Claessensxclae...@gmail.com wrote: Ubuntu told me that Maverick (the next ubuntu release) is not going to ship GTK3 I don't think that's true. I was at the planning session for coming changes in GNOME at UDS Maverick, and the plan of record was to include GTK+ and GNOME 3.0. https://blueprints.launchpad.net/ubuntu/+spec/desktop-maverick-gnome Talked to an ubuntu dev, their problem is they don't have enough free space on the liveCD to have version 2 and 3 of all libraries. And I doubt we'll be able to port all app that they ship on the liveCD to gtk3 in time... Or could we? Regards, Xavier Claessens. ___ 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
Le 12/06/10 14:49, Bastien Nocera a écrit : 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) https://bugzilla.gnome.org/show_bug.cgi?id=618473 Emmanuele could do a release. - 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 :-) Why is losing GTK2 compatibility a problem? It shouldn't matter. You could create a gnome-2-32 branch and make changes there if you wanted. Ubuntu told me that Maverick (the next ubuntu release) is not going to ship GTK3, and if we can't build Empathy with GTK2 then they'll just keep Empathy 2.30.x... tbh I think that's a bad decision from Ubuntu, but it would be really sad to not ship the latest empathy... But I guess if the whole GNOME 2.32 depends on GTK3 then they'll change their mind. Regards, Xavier Claessens. ___ 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
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) - 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
Re: Modulesets Reorganization
Le 02/06/10 01:37, Lucas Rocha a écrit : In summary, this means that the GNOME releases would be composed by the following modulesets: - Desktop - Platform - Extended Platform - Mobile That seems a very good idea. There were indeed a need to get bindings on the platform, and extend the platform is a good module set for libraries that aims to be in the core platform but are not there yet (API/ABI stability reasons, etc). With that organisation I think libtelepathy-glib could already be promoted into 'Extended Platform'. It will be directly used by Empathy and Gnome-Shell at least. I also think it's used by vinagre. So this is a big +1 from me (for what I worth) :-) The long term plan for the GNOME applications that were removed from the Desktop, Admin and Dev Tools modulesets is to simply highlight the high-quality applications using the GNOME platform through our communication channels (release notes, website, etc). There will be no official apps anymore and no 'Applications' moduleset in the GNOME releases. The goal here is be more open with the app developer community around GNOME and to highlight all the nice things that can be created using our platform. I understand the difficulties to maintain an Application moduleset, and the need to extend a bit the definition to more modules, but I don't think this is the right solution. With that definition, Pidgin is as GNOME as Empathy then ?!? That means that GNOME applications could live in any VCS, on any server/infrastructure, with any licence, etc ?!? That will be a mess. Also the current (already legacy?) method to propose an application in the GNOME desktop was a good opportunity to get community feedback, get more developers involved in the projects, and fix lots of GNOMEy issues the app could have. Also that was an opportunity for the app to move to the GNOME infrastructure. I take my experience with Empathy for this, we moved it to GNOME infrastructure in preparation of proposing it into desktop, it was a pain because of SVN but we did it (with new system I would certainly not have moved it to GNOME's SVN and would have kept it in Collabora's git). Also the first time I proposed Empathy it was rejected with a good list of reasons, those got worked on and that gave goals for the next 6months. That resulted in a better app proposed the next cycle and got approved. If we remove that module proposal for the desktop, things could have been different. And my last issue with the proposal: All applications could decide their own release schedule ?!? That would be a total nightmare for distributions I think. See how GTK not following GNOME schedule proved to be a recurrent issue... See for a concrete example that could happen: During the GNOME 3.1.x dev cycle, Empathy is following the same cycle and Ubuntu decide to ship Empathy 3.1.x for their dev cycle too. Then 2 days before the GNOME 3.2.0 release, Empathy decide - since they are not really bound to any GNOME schedule anymore - to add new features to their 3.1.x unstable branch and delay the 3.2.0 stable release for 2 extra months. What is supposed to do Ubuntu for their planned stable release?? They revert to Empathy 3.0, or they delay their distro release for 2 months? So my opinion is we really still need an *official* 'Applications' moduleset, with strong requirements to get in. Though, we could make it more flexible, for example we could accept 2 applications doing the same job without deciding which one is best (rhythmbox + banshee, empathy + ekiga). After all deciding which app is best is really a distro decision and does not limit to GNOME (epiphany VS firefox). I think we should give to distro a set of applications that follows strong rules (licence, release schedule, freeze periods, infrastructure used, defined set of external dependencies, etc) then let them pick the app they like in that set. Regards, Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
Le 02/06/10 08:50, Xavier Claessens a écrit : Also the current (already legacy?) method to propose an application in the GNOME desktop was a good opportunity to get community feedback, get more developers involved in the projects, and fix lots of GNOMEy issues the app could have. Also that was an opportunity for the app to move to the GNOME infrastructure. I take my experience with Empathy for this, we moved it to GNOME infrastructure in preparation of proposing it into desktop, it was a pain because of SVN but we did it (with new system I would certainly not have moved it to GNOME's SVN and would have kept it in Collabora's git). Also the first time I proposed Empathy it was rejected with a good list of reasons, those got worked on and that gave goals for the next 6months. That resulted in a better app proposed the next cycle and got approved. If we remove that module proposal for the desktop, things could have been different. Another example I just though, again taking my experience with Empathy: Before proposing Empathy in GNOME desktop I (as Empathy maintainer) didn't know *anything* about accessibility. Proposing Empathy the first time resulted in some issues raised about accessibility because the few people that understand that are reading ddl module proposals, and tests applications proposed. Probably Empathy still has accessibility issues, and surely I still do not understand fully what should be done for that, but at least Empathy being officially part of GNOME generated interest about its accessibility and we got contributions in form of patches, bug reports, informative discussions, etc. If Empathy was hosted on, say, launchpad, and did not got through an approval process to get in GNOME desktop, I'm sure I still wouldn't know that accessibility exists in GNOME. And Empathy is not the only example here, most app proposals ends in accessibility issues... Regards, Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Fwd: Proposing new external dependency for Empathy: libfolks]
Le 26/05/10 18:45, Xavier Bestel a écrit : On Wed, 2010-05-26 at 09:19 -0700, Travis Reitter wrote: On Wed, 2010-05-26 at 17:37 +0200, Xavier Bestel wrote: On Wed, 2010-05-26 at 08:23 -0700, Travis Reitter wrote: Just to clarify a little, it would look like this: telepathye-d-s | | V V telepathy-vala libebook-vala | | | | ++---+--+---+ |libfolks| | | | ++ V V | | TpPersona EPersona | | \ / | |V | |Individual | || | ++--+ | V applications Does that mean that, when I sync from Evolution, I'm loosing a part of the information constituting an Individual ? What kind of syncing, specifically? libfolks' Personas are designed to stay synchronized with their original sources (through their per-backend PersonaStore, which I left out of the diagram above for simplicity). If the EContacts in e-d-s change state (eg, you synchronize them from another addressbook, change them in Evolution itself), libebook will signal the changes, EPersonaStore will handle the signals and update its EPersonas (including adding/removing full EPersonas, as necessary), and each EPersona will signal the changes. The Individual will notice the changes and update its exposed attributes (and emit its own signals). Does that answer the question? I'm not sure. Say I have a central server where I store my contacts, and 2 workstations syncing to that server through Evolution. If I add some information (e.g. a Facebook id) to an Individual with Empathy on a workstation, will it appear on the other workstation ? Xav First, I don't think Empathy should be a full vCard editor. That said, if empathy (or any app, include Evolution) edit a contact, the new vCard is stored in E-D-S and sync system will just replicate that change in other PCs. I think that process is totally transparent to libfolks. The only thing to take care is to not change the UID of the EContact in the sync process, otherwise the contact will unmerge. Or did you mean if I merge a TpContact (say, a Jabber contact f...@jabber.org) and an EContact together into an Individual, the EContact should be added a vCard attribute x-jabber=...@jabber.org and that info sync in other PCs? That could be done, but I don't think that's necessary. Regards, Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Fwd: Proposing new external dependency for Empathy: libfolks]
Le 25/05/10 15:11, Matthias Clasen a écrit : On Tue, May 25, 2010 at 5:07 AM, Frederic Petersfpet...@gnome.org wrote: Hello all, It arrived late and was limited to the release team, but as we didn't announce module decisions yet, if you have any comment on this proposal for a new external dependency, please speak up. I would like to know how this will fit with the gnome3 user experience ideas; will it become the backend for a desktop-wide contacts application ? Has this been discussed with the evolution guys ? The goal is indeed to make it desktop-wide, like everything in the spirit of Telepathy. But for the 2.31 cycle, it will probably not be used yet by any other app than Empathy. We don't have API guarantees yet AFAIK. It is planned for libfolks to be able to use any source of contacts information and merge them. Currently we take only Telepathy contacts, but an EDS backend is on the Roadmap (probably not for 2.32 though). Regards, Xavier Claessens ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings and you
Nice. Just a question: where can I find the code for the Several fully functional backends? Especially the gconf one. Thanks, Xavier Claessens. Le 20/04/10 15:30, Matthias Clasen a écrit : Hey, with the GLib 2.25.1 and GConf 2.31.1 releases that I've made yesterday, the results of last weeks GSettings hackfest are now available. Some pieces of the puzzle are still missing: - Dconf is still being worked on - Support for lists of settings (like a lists of accounts, or /desktop/gnome/url-handlers) is not there yet - The handling of enums is not very convenient yet But we have more than enough in place now to let you start porting applications: - Several fully functional backends - API documentation: http://library.gnome.org/devel/gio/2.25/settings.html - Man pages: http://library.gnome.org/devel/gio/2.25/tools.html - A porting guide: http://library.gnome.org/devel/gio/2.25/ch23.html - An example: http://git.gnome.org/browse/gnome-utils/log/?h=gsettings-tutorial Playing around with what we have now would be very helpful for discovering the (undoubtedly existing) oversights and omissions in the GSettings API. We recommend to use the GConf backend (see the gnome-utils example for how to do that) until dconf is ready for prime time. So, the race is on for the first release of a GSettings-based application. Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Appearance properties
Hi, In GNOME 2.28 some default settings changed for the desktop: 1) In toolbar, text is next to icon instead of below. 2) Icons got removed from menus. 3) Icons got removed from action buttons in dialogs. 1 and 2 were still configurable from gnome-appearance-properties, 3 was not possible to change (Bug #595341). And now the whole interface tab was dropped. Making 1, 2 and 3 not configurable anymore (Bug #592756). Am I the only one to think something really insane is happening? It seems all those decisions are taken by a few developers that like that... This impact the whole desktop and is very visible to all users, so I think the discussion should be wider. That's why I'm posting here. So if you agree/disagree with those changes, please tell your opinion! I would like to know if I'm the only one to be worried. Regards, Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Appearance properties
Le mardi 10 novembre 2009 à 10:19 +, Thomas Wood a écrit : On Tue, 2009-11-10 at 10:18 +0100, Xavier Claessens wrote: So if you agree/disagree with those changes, please tell your opinion! I would like to know if I'm the only one to be worried. Well, I'll repeat what I said on the bug: I agree with McCann, if someone wants to tweak their settings in such a way, then it should be done through an appropriate tweaks application. The interface tab does not contain options that are of interest to the majority of users. Can you please tell me what's gnome-appearance-properties if it is not to tweak the appearance of the GNOME desktop? The fact that those options are useless for the majority of users is highly debatable and should definitely not depend on you+McCann alone. I would like wider acceptance before. I definitely give a -1, but if I'm alone then ignore me ;) Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Appearance properties
Le mardi 10 novembre 2009 à 10:56 +, Bastien Nocera a écrit : On Tue, 2009-11-10 at 11:28 +0100, Xavier Claessens wrote: Le mardi 10 novembre 2009 à 10:19 +, Thomas Wood a écrit : On Tue, 2009-11-10 at 10:18 +0100, Xavier Claessens wrote: So if you agree/disagree with those changes, please tell your opinion! I would like to know if I'm the only one to be worried. Well, I'll repeat what I said on the bug: I agree with McCann, if someone wants to tweak their settings in such a way, then it should be done through an appropriate tweaks application. The interface tab does not contain options that are of interest to the majority of users. Can you please tell me what's gnome-appearance-properties if it is not to tweak the appearance of the GNOME desktop? The fact that those options are useless for the majority of users is highly debatable and should definitely not depend on you+McCann alone. I would like wider acceptance before. I definitely give a -1, but if I'm alone then ignore me ;) You're confusing this place for a democracy :) We might as well enable Bugzilla voting otherwise. The reasons behind the move have been documented, and explanations given on how to get the icons back. Actually I started this thread because starting from today, GNOME does not have any way to get icons back anymore. gconf-editor is not considered a tweak application ;-) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: RE: Appearance properties
Le mardi 10 novembre 2009 à 10:24 +, Thomas Wood a écrit : On Tue, 2009-11-10 at 11:14 +0100, Olivier Le Thanh Duong wrote: I agree with Xavier. In the bug report they say this should be moved to a tweak application but isn't this capplet already a tweak application? A tweak application is would be one that changes little-used and low importance preferences. The Appearance capplet includes three sections. Background is probably most used, Font is of high importance (for accessibility) and Theme is probably a medium priority preference. I think, but could be wrong, that tab was indeed useless... until the sane default changed and became unusable/ugly... now it is really useful to get back to previous configuration, so the interface tab is now really important. Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Appearance properties
Le mardi 10 novembre 2009 à 13:27 +, Bastien Nocera a écrit : On Tue, 2009-11-10 at 08:24 -0500, Jud Craft wrote: It's not forbidden and in fact, in 2.28, you can still change this option through the appearance capplet. I think you may be mistaken. I'm running GNOME 2.28 on Fedora 12 and the Appearance Properties no longer allow you to do this, since the Interface options mentioned above have been removed. That's because Fedora is ahead of upstream :) Just like we disabled the icons and fixed a number of apps before this got upstream. Obviously they missed inkscape... But since we don't have icons I guess inkscape is not useful anymore... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Appearance properties
Le mardi 10 novembre 2009 à 14:23 +, Bastien Nocera a écrit : On Tue, 2009-11-10 at 09:04 -0500, Pierre-Luc Beaudoin wrote: On Tue, 2009-11-10 at 10:55 +0100, Ruben Vermeersch wrote: While I generally trust designers in their judgement and I agree that there was an icon overload, I now often feel a lack of icons. My menu usage has slowed down because I now have to read everything instead of being able to rely on icons. A good example of slowed down usage is Inkscape. Open the Path menu and you have to read most of them to actually find Division where it used to be a quickly identifiable by its icon (not to mention that the difference between Division and Exclusion was better served by an icon). That's a bug in inkscape. If it _requires_ the icons to be useful or usable, then it should force the icons to be visible in those menu entries. It would have broken the same way before if a user disabled icons in the menus themselves through the GConf key. Having a ton of icons is certainly not good, but is there anything that shows that having none at all is better? That's my 2 cents as a user: unless studies have generally identified a speed up in menu usage, I would think it was a move the opposite. There's a bugzilla with plenty of reasons behind this change. You're more than welcome trying to second guess our esteemed community usability people. I think most of the anger in this thread stems from the fact that it's changed. Well, progress comes through changes, and nothing was ever achieved with status quo. Maybe we'll change our minds later, but without compelling arguments, it's hard to make a case for reverting this change now. Actually I don't want to complain here because it changed. I'm against but I can accept... What I find totally insane is to not leave the UI to change that. New settings is clearly not accepted by a large (majority?) part of users. Except ~5 devs, I see nobody happy with it. So the minimum required is a UI to tweak that... in *official* distribution, not some package totally unmaintained and unknown that nobody will ever install. Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Appearance properties
Le mardi 10 novembre 2009 à 16:36 +, Bastien Nocera a écrit : On Tue, 2009-11-10 at 17:23 +0100, Frederic Crozat wrote: Le 10/11/2009 15:23, Bastien Nocera a écrit : snip It is quite simple : this change affected all ISV (we could say inkscape was an ISV for instance, or Firefox) which were using GTK+, without any kind of prior notification to be able to fix their application. That is the reason why I had to revert the icon in button and icon in menu on Mandriva Linux 2010. Vendors had 4 months head-way to test for changes, and fix them. If 4 months isn't enough, I'm not sure how much advance warning we need to give for something so easily fixable. The issue here is too few people are running dev version of GNOME desktop. Also lots of people just assumed that it was a stupid bug that will quickly be fixed. Also we don't have ML to announce the big changes in GNOME. A little email can easily be sent to ddl without being really noticed by users and third parties. Did you announced that setting change before apply the patch and waited for advices? Did you announce that interface tab is going to be removed? I'm not even sure that was on ddl... and even if that was the case, I think it's not enough... Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: dconf
Le mardi 13 octobre 2009 à 23:06 +0200, Luca Ferretti a écrit : 2009/10/13 Rodrigo Moya rodr...@gnome-db.org: Ryan is a bit sad to not get feedback on his proposal, so a bit more seriously: I think what we probably need is a migration plan. Should we move all the code from gconf to dconf in one cycle (if possible)? Should apps implement migration for the data in gconf? etc. I think it makes sense to do the migration for all the apps at once. Are we speking about: a) all GNOME Desktop applications b) all applications hosted on git.gnome.org c) all GNOME/GTK+ apps using GConf :) ?? Serius: what's the plan for thirdy part applications? I guess gconf is going to be unmaintained and deprecated for GNOME. It is already largely unmaintained AFAIK. So use gconf at your own risk, or switch to dconf to be sure you are using maintained code that will get fixes. So this apply at least to all GNOME desktop applications, but really should be followed by any app using gconf IMO. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: dconf
Le lundi 12 octobre 2009 à 11:27 -0400, Ryan Lortie a écrit : I'd like to propose the inclusion of dconf for GNOME 2.30 in the desktop release set. This is great news! I'm all in favor of dconf. Do you have plans to move to GNOME plateforme? IMO that really should replace gconf for GNOME3, this should be part of the cleanup plateform goal IMO. However I have a few questions: - How do we migrate user settings from gconf to dconf? If it is not done on GSettings/dconf level, that means that all applications will still have to link on libgconf to read old values and save them on new dconf keys at startup, and set a flag settings converted so that conversion is ran only once. - Does dconf supports lockdown, so administrators have a way to force a value for some keys and the user don't have permission to modify it? Congratulation for your hard work, I hope that will succeed :D Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Icons in menu and dialog action buttons
Hello, I just installed GNOME 2.27.92 (Ubuntu Karmic) and I see that by default all icons are removed from menus and from dialog action buttons. I'm not starting a flame about is it the right thing to do, but my personal opinion is that it's totally stupid... But what is even worse is that users don't even have an UI to change that!!! I can go to the interface tab to get the previous behaviour for menu and toolbar, but there is not even an option to get back icon in dialog's action buttons. Sorry but this is not acceptable at all. I can accept that the default change, but not having an UI to get back old behaviour is irresponsible (no, a gconf key is not enough!). I opened a BLOCKER bug #595341. I think the release team should make the decision to not release GNOME 2.28.0 until it gets fixed. Thanks, Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Empathy branched for 2.28
Hello, I branched Empathy for GNOME 2.28. Stable branch is now gnome-2-28 and master is for the work toward GNOME 2.30/3.0 Regards, Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Libglade officially deprecated in favor of GtkBuilder.
Le lundi 11 mai 2009 à 11:31 +0200, Murray Cumming a écrit : On Mon, 2009-05-11 at 00:26 +0200, Andre Klapper wrote: Hi, The GNOME Release team has officially deprecated libglade in favor of GtkBuilder. Some reasons: * GtkBuilder is actively maintained. * GtkBuilder can create non-widgets (like treemodels). * It's one less library. Aim is to get rid of libglade for GNOME 3.0. This is also covered by the schedule at http://live.gnome.org/TwoPointTwentyseven . For the status of your module see the LibGlade column in http://www.gnome.org/~fpeters/299.html . For migration instructions see http://library.gnome.org/devel/gtk/stable/gtk-migrating-GtkBuilder.html . Also see http://live.gnome.org/GnomeGoals/RemoveLibGladeUseGtkBuilder . I think this is just slightly premature. GtkBuilder is still not fully able to deal with multiple top-level-widgets per file, as was usual when using libglade, and which is still supported by Glade's UI. http://bugzilla.gnome.org/show_bug.cgi?id=575714 Also, when there are GtkMenu defined in a glade file, the gtk-builder-convert script will generate a GtkUIManager, but if I open that generated file with glade-3, and save again, the ui manager is gone... Files saved with glade-3 contains GtkMenuItem widgets but loading that file generate GtkAction objects instead... Is there a bug open for that? Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bumping telepathy-glib to 0.7.27 (Empathy needs that version)
Le jeudi 23 avril 2009 à 12:41 +0200, Jaap A. Haitsma a écrit : Hi, I just noticed when using jhbuild that empathy needs 0.7.27 of telepathy-glib. OK to bump the version in jhbuild and http://live.gnome.org/TwoPointTwentyseven/ExternalDependencies telepathy-glib as good regression tests and its ABI/API is guaranteed to be stable. So I think the external dep should be set has 0.7.x. I always forget to edit that page... IMHO setting an exact version as external dep for GNOME only makes sense when there is an ABI break. Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Git migration Thursday?
Hello, Is it still true that the SVN-GIT migration will take place tomorrow? I guess the SVN will be set read-only during the import, at what time will it happen? Do we have an estimation of how long it takes? Maybe all that was already answered on some emails I missed? Thanks! Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Bump version of telepathy-glib to 0.7.19
Hello, I bumped required version of telepathy-glib to 0.7.19 (external dep). It is needed for latest Empathy. There is no known regression and API is stable so I think it shouldn't be a problem. Xavier Claessens. ___ 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
Le dimanche 11 janvier 2009 à 20:08 +0100, Wouter Bolsterlee a écrit : 2009-01-11 klockan 19:52 skrev Guillaume Desmottes: Le dimanche 11 janvier 2009 à 16:21 +, Sjoerd Simons a écrit : [...] add telepathy-farsight[0] as an external dependency for that for Empathy's voip support. [...] Just to complete this, the advantages of this switch include: - Farsight 2 can use more video codecs than Farisght 1. That means we'll be able to use, for example, Theora as so have video conferencing working out of the box (FS1 supports only H264 which is patented). Out of curiosity, how does this relate to the functionality offered by Ekiga? If there is overlap, perhaps some integration work is in place? I don't think it really change the situation. There is some overlap with Ekiga from the beginning. However empathy is not a softphone, Ekiga is by far more mature and has lots more features than empathy for SIP voice/video. Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Empathy branched for 2.24
I created gnome-2-24 stable branch for Empathy. See the Roadmap[1] for more details of what's coming in trunk. Xavier Claessens. [1] http://live.gnome.org/Empathy/Roadmap ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: enable accessibility by default for GNOME
On jeu, 2008-07-31 at 13:14 +0800, Tao, Miao wrote: I think what we did here is for a better user experiences to accessibility users, just like what Will said, it's far easier for someone without a disability to turn it off than it is for a person with a disability to turn it on. At installation of the distro you already need some accessibility, so I think it's distro's responsibility to ask in an accessible-way the user if he wants accessibility turned on or not at the first stage of the installation of the system. Depending on what the user answers it's distro's responsibility to enable/disable it in GNOME. Another way is to enable/disable depending on the presence of special accessibility hardware connected. And finally, we could have an option in GDM to enable accessibility for the new login, like pressing F7 or clicking a button somewhere... So my opinion is there is no reason to enable it by default for people that don't need it, but we should instead make sure it's damn easy for people with disabilities to enable it. Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: enable accessibility by default for GNOME
On jeu, 2008-07-31 at 11:32 -0400, Willie Walker wrote: 4) Keep it off by default. Provide some sort of refresh this session support that keeps the user logged in, but basically kills everything on the desktop and restarts gnome-session. With this, users would have the similar you must enable accessibility support experience that they have today, but they wouldn't need to log out and log back in. Note also that this should probably be coupled with the user experience for selecting the automatic start of an assistive technology when the session starts. Why not simply add the accessibility configurations in GDM before login? We could simply have a button [Normal login] [login with accessibility enabled and remember I always want accessibility in the future]. Like that we don't have to restart all applications since it's enabled before all GTK app gets started. Xavier. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: empathy
Le lundi 28 juillet 2008 à 00:31 +0200, Vincent Untz a écrit : Homepage: http://live.gnome.org/Empathy svn/git/bzr/...: http://svn.gnome.org/viewcvs/empathy/ You can also use git://git.collabora.co.uk/git/empathy.git Summary so far: === + (would be nice to get an overview of what has changed since 2.22 proposal -- I believe Xavier will send something about this) + hosted on the GNOME infrastructure + following the GNOME release schedule + supported by many people, but a few -1 were sent too + lots of discussion about the licensing issues: people really want the libraries to be LGPL. See below for details/updates about this. + comments about bad support for IRC, but also feelings that this shouldn't block the inclusion. A SoC student is working on this, I hope we can improve it for 2.25.x, but 2.24 will get little bug fixes only. Some update about those items (correct me if I'm wrong): + about features stability: feedback is welcome. Xavier will probably send an update. New features: - Audio/Video call is now enabled by default. The UI improved a bit but there is still lts of work needed to get it right. However audio/video works with SIP (video is not compatible with ekiga for codec reasons) and Jabber (audio is compatible with gtalk). Empathy also now supports DTMF signals so you can answer when a voice tell you Pour continuer en français, appuiez sur le 1. For English, press two.. - User manual started, but it is far from complete... Help is needed! - libgnome-vfs is totally replaced by gio. - Support for MSN-like chats that becomes suddenly a chatroom when someone gets invited. - Register new account for protocols which supports that like Jabber. - Passwords are stored in keyring. - Add Tube support. See this page for more info how you can make use of Tubes for your application: http://live.gnome.org/Empathy/Dispatcher For future plans see http://live.gnome.org/Empathy/Roadmap + the keyring is now used (afaik). If you are using recent MissionControl, yes. + I believe that the plan is to slowly move the empathy libraries into telepathy and that code might get rewritten for this because of LGPL needs. Only a promise so far, though. This might mean we should only consider the empathy application for inclusion (and try to forget about libraries). libempathy and libempathy-gtk are proposed as public API for experimental work only. Those 2 libraries will NEVER be proposed for inclusion in GNOME platform. There is no rule requiring libraries of the DESKTOP to be API-stable(except for freezes), fully documented API and LGPLv2+. If that's still a problem we can just make those 2 libraries private and link statically the empathy client on them but that would be a big lost for projects who already started integrating IM capabilities. Please consider inclusion of Empathy as a stand-alone IM client. Integration possibilities are already possible for experimental stuff and will mature in the future. The plan comes in 2 steps: 1) Reduce the need of additional high-level library by improving the Telepathy spec. Collabora is actively working on simplifying the spec atm. 2) Add more high-level API in libtelepathy-glib when needed. libtelepathy-glib is a LGPLv2+ and 100% documented library, any additional code must follow that rule. For that we'll either write new code or copy LGPL code from libempathy. An important fact here is lot/most of the API of libemapthy is not really needed for third party clients and most of the useful parts is already LGPLv2+. For libemapthy-gtk things are a bit more complicated because most of the code comes from Gossip and is GPLv2+. But again not all widgets are really useful for third-party clients. We are planning to create libtelepathy-gtk library following the same rules than libtelepathy-glib. Note: The work already started, latest libtelepathy-glib release has code to help using the Group interface which deprecates EmpathyTpGroup object from libempathy. Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed external dependency: libcanberra
Le lundi 28 juillet 2008 à 00:36 +0200, Vincent Untz a écrit : Short description: == libcanberra is a sound event library implementing the XDG sound theming/naming specs. I don't know if it's stable and solid but for what I've seen of the API and the idea behind it's definitely a +1 from me! I've been waiting for such fd.o sound theme for years. Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed external dependency: libcanberra
Le lundi 28 juillet 2008 à 00:36 +0200, Vincent Untz a écrit : Homepage: ? Proposal on d-d-l: http://mail.gnome.org/archives/desktop-devel-list/2008-July/msg00075.html License: LGPLv2 or later (I believe) Short description: == libcanberra is a sound event library implementing the XDG sound theming/naming specs. Summary so far: === + no real comment so far Vincent I have a question: Is libcanberra-gtk the definitive library or is there plans to move the code directly into GTK+? Or is there good reason to have it outside GTK+? The API could be gtk_widget_play_sound(GtkWidget *widget, uint32_t id, ...); Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed external dependency: libcanberra
Le lundi 28 juillet 2008 à 16:08 +0200, Lennart Poettering a écrit : I have a question: Is libcanberra-gtk the definitive library or is there plans to move the code directly into GTK+? Or is there good reason to have it outside GTK+? The API could be gtk_widget_play_sound(GtkWidget *widget, uint32_t id, ...); For now I see no reason to do this. It might be a good thing to do this eventually, to allow tighter integration of sounds with input events (i.e. instead of hooking into all kinds of signals via the GtkModule we could make gtk call those functions directly). But the question then would be how much to actually move into gtk. Only lc-gtk? The entire lc? The entire lc would mean moving a complete set of backends for the various sound systems into gtk. Would that be a good idea? Dunno. Just lc-gtk? Would that be sufficient? Also, the raw lc api is still very much visible through lc-gtk, since lc-gtk is not an abstraction, just a bit of glue code. Would it be such a good thing then to add it to gtk? also, what would be the real benefit of moving only lc-gtk into gtk? it's now shipped with lc, it would then be shipped with gtk. You'd need both packages anyway, so it would not exactly help on our dependency hell issue, would it? lc is still pretty new. Let's keep it outside of gtk for now. See how things work out and maybe merge it or parts of it later. So, it's not a no, or a yes. But a maybe later. Ok thanks. Personally I don't know what's the best, I just asked to know if there is plans about that or not. gtk_widget_foo and gdk_event_foo seems more appropriate than ca_gtk_foo but it's a really minor inconvenience. Xavier. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.24 module inclusion discussion heats up
Le vendredi 04 juillet 2008 à 23:22 +0200, Andre Klapper a écrit : From a quick search through the archives it seems that also PolicyKit, Clutter, ClutterMM, and libgda have been proposed as external dependencies but aren't listed in the wiki. Is that right? Empathy needs libtelepathy-glib and libmissioncontrol-client as external dependencies. Note that libmissioncontrol-client will probably be drop for GNOME 2.26. Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.24
Hello, Here are news about Empathy. Biggest objections for inclusion were: - Empathy depends on libmissioncontrol-client which is LGPLv2.1-only: This situation won't change in time for GNOME 2.24, however this library will be deprecated probably during the 2.25 cycle in favor of a new spec and API in libtelepathy-glib which is LGPLv2.1+. - Empathy has no user manual: This is not true anymore[1], a manual is being written and is already included. It is far from complete but Milo Casagrande is working on it, help is needed to finish it in time I think. - libempathy and libempathy-gtk are GPL and not documented: We agreed that those libraries won't be proposed for the GNOME platform, never. They are proposed for experimental purpose in the DESKTOP. Useful bits of libempathy(-gtk) will be moved to libtelepathy-glib and (probably new) libtelepathy-gtk once they are API stable, documented and LGPL. Most parts potentially useful for telepathy-glib are already LGPL, the rest could be rewritten or licencing change will be asked if/when needed. libtelepathy-glib is fully documented[2]. - Passwords are stored in gconf: This is not true anymore, if libmissioncontrol-client is build with libgnome-keyring passwords are stored in the keyring and not in gconf anymore. If you upgrade MC from a previous version make sure to retype the password of every account to be sure they are removed from gconf and added to the keyring. Notes: - libtelepathy is now deprecated an empathy do not depend on it anymore, replaced by libtelepathy-glib - libempathy and libempathy-gtk are only continence API to make easy to write applications, but everything can be done through DBus so it's totally licence-independent. [1] http://library.gnome.org/users/empathy/unstable/ [2] http://library.gnome.org/devel/telepathy-glib/unstable/ I hope this will help the adoption of Empathy for GNOME 2.24. Xavier Claessens. 2008/3/25 Xavier Claessens [EMAIL PROTECTED]: * Proposal: Include Empathy in GNOME 2.24 desktop. * Purpose: Empathy [1] consists of a rich set of reusable instant messaging widgets, and a GNOME client using those widgets. It uses Telepathy and Nokia's Mission Control, and reuses Gossip's UI. The main goal is to permit desktop integration by providing libempathy and libempathy-gtk libraries. libempathy-gtk is a set of powerful widgets that can be embeded into any GNOME application. * Dependencies: glib-2.0 = 2.16.0 gconf-2.0 = 1.2.0 libxml-2.0 libtelepathy = 0.3.2 telepathy-glib = 0.7.3 libmissioncontrol = 4.53 gtk+-2.0 = 2.12.0 libglade-2.0 = 2.0.0 libebook-1.2 libpanelapplet-2.0 = 2.10.0 * Resource usage: Already using GNOME FTP, GNOME SVN and GNOME bugzilla. * Adoption: It is packaged at least for debian, ubuntu, mandriva, gentoo and fedora. There is patches for Totem and nautilus-send-to [2] to make use of libempathy(-gtk). There is a gtetrinet branch which uses libempathy-gtk to play with contacts. There is also a python plugin for epiphany using pyempathygtk [3]. Empathy is also used by Soylent [4]. * GNOME-ness: The community reports bugs in GNOME bugzilla and attach patches, I review and commit in GNOME's SVN. GNOME translation teams are already translating empathy. The UI is build with GNOME spirit in mind, empathy inherit from Gossip's excellent UI. * Miscellaneous: - Audio/Video support is still disabled by default but most problems comes from other telepathy layers and are being worked. I'm pretty sure it will be enabled soon. That means Empathy will be able to do audio/video calls over SIP and Jabber, MSN will surely come at some point too. Empathy is the only program capable of that AFAIK. - libtelepathy is now deprecated, empathy is moving to telepathy-glib. If we finish the transition we'll drop libtelepathy dependency. - Empathy's part for file-transfer is almost done, but the telepathy spec is likely to change soon. I hope it will be ready in time for 2.24. - API is still not documented and likely to change, I know this sucks. - There is no user documentation yet, I'll write an email to ask documentation team to write one base on Gossip's doc. - Empathy was proposed for GNOME 2.22 but got rejected because it was not considered stable/mature enough. Lots is already fixed and I hope to fix more during the 6 months coming. Help from the community is of course welcome! Thanks, Xavier Claessens. [1] http://live.gnome.org/Empathy [2] http://www.barisione.org/blog.html/p=100 [3] http://blog.senko.net/2007/07/19/emphatic-epiphany [4] http://live.gnome.org/Soylent ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: application names in the application menu
Le vendredi 28 mars 2008 à 18:30 +0100, daniel g. siegel a écrit : hi! im writing this mail because i am very confused (and no, it is just now ;) ). in cheese we plan to change the description of the application menu entry, as it is somehow misleading. we want to change it to Take photos and videos with your webcam. so far everything seems to be alright. but as vincent untz said on [1] We try hard to not put the name of the programs in the menus, for many reasons. It doesn't translate well, for example. as we would change our description the application menu entry would look like: Cheese - Take photos and videos with your webcam recently, i showed some pupils the gnome desktop and what i noticed was, that they even didnt know what Cheese meaned, or what program would open if he had clicked on it. this wasnt only on cheese, but also on epiphany, dasher, and others (some choose their name like [name] [small description], e.g. f-spot photo manager, which is more understandable, even if the program name doesnt make sense for a person, which is new to gnome). They just could figure it out, by interpreting the icon. now i learned, that it was very confusing to have names like nautilus, epiphany, cheese for a guy, who hears those names for the first time. so it would be better to have menu entries like Texteditor (gedit) or Document viewer (evince). but then, who would know how the application should be called? how could he then submit a bug report to _that_ program? how can the person find the projects website on a search engine? is a program name senseless? please clarify this issue for me ;) [1]: http://bugzilla.gnome.org/show_bug.cgi?id=512091 I think that's why we have the help-about dialog with the name of the application and the website. Isn't that enough? In my opinion showing in the applications menu what the app does instead of the application's name is *really* good. Last time I looked windows is was thinks like Start-programs-Sierra-Half-Life-Half-Life which is complete non-sense. Xavier Claessens. Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.24
Le jeudi 27 mars 2008 à 11:35 +, Alberto Ruiz a écrit : Actually, I find a bit scary to find out that a future maintainer is not careful at all with third party copyright/licensing while moving code. Please tell me want your are basing this accusation? I kept GPL licence and Imendio copyright for everything that comes from Gossip, I'm very careful on that. Maybe I did a mistake but so far nobody showed me a file with wrong copyright/licence. So don't be scared, I'm a very careful maintainer ;-) Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.24
Le jeudi 27 mars 2008 à 09:26 +, Martyn Russell a écrit : Xavier Claessens wrote: Ok so I summarize so far here are objections: 2) libempathy and libempathy-gtk are GPL This is only a problem if we want them in the plateform. Currently it's proposed for the desktop so it's not a problem yet. It will be a problem when we want to move them in the plateform. If I see copyrights in GPL headers of all Empathy files I see Imendio+Collabora+some personal that are ok to relicence. We have to contact all other little contributors but I think those are not a real obstacle if we ask on gossip's mailing list + grap emails in the changelog. The problem here is mostly imendio who owns most of libempathy-gtk. And most of libempathy. Files without copyright/author information which should be updated include: - libempathy/empathy-chatroom.[ch] Mostly rewritten in empathy, it's not only a property container that does nothing. empathy-chatroom.c is 361 lines, gossip-chatroom.c is 1144... - libempathy/empathy-log-manager.[ch] I left imendio copyright and gossip-log does not have any author in the GPL header. I rewrote most of that module, empathy-log-manager.c is 799 lines and gossip-log.c is 2789... - libempathy-gtk/empathy-account-widget-jabber.[ch] - libempathy-gtk/empathy-account-widget-msn.[ch] *I* wrote those in gossip before the empathy fork. And those files does not exist in empathy HEAD anymore. - libempathy-gtk/empathy-main-window.c - libempathy-gtk/empathy-spell-dialog.c The imendio copyright is still there and corresponding file (gossip-app.c and gossip-spell-dialog.c) does not mention any author. So I don't see where is the error, have you objections or other wrong files? Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.24
- libempathy/empathy-chatroom.[ch] Mostly rewritten in empathy, it's not only a property container that does nothing. empathy-chatroom.c is 361 lines, gossip-chatroom.c is 1144... sorry for the typo: s/not only/now only/ Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.24
- libempathy-gtk/empathy-account-widget-jabber.[ch] - libempathy-gtk/empathy-account-widget-msn.[ch] *I* wrote those in gossip before the empathy fork. And those files does not exist in empathy HEAD anymore. Hum, sorry, it seems I could be wrong on this, looking at bug #358099 it was indeed copied code not fully written by me. Anyway those files got removed from empathy. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.24
Le mercredi 26 mars 2008 à 10:25 +, Martyn Russell a écrit : Xavier Claessens wrote: Le mardi 25 mars 2008 à 07:01 -0500, Travis Watkins a écrit : Did anything ever happen with the license issues for the libraries? They should be LGPL. Any they won't be. Both libempathy and libempathy-gtk use a lot of GPL code from Gossip and some of the files are not correctly attributed with the authors too I noticed. If there is errors please tell me and I'll fix authors asap. Thanks. Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.24
Le mercredi 26 mars 2008 à 18:05 +0100, Patryk Zawadzki a écrit : On Wed, Mar 26, 2008 at 5:56 PM, Travis Watkins [EMAIL PROTECTED] wrote: On Wed, Mar 26, 2008 at 5:25 AM, Martyn Russell [EMAIL PROTECTED] wrote: Both libempathy and libempathy-gtk use a lot of GPL code from Gossip and some of the files are not correctly attributed with the authors too I noticed. So it is a -1 for that reason for me. In that case -1 from me as well. If it's not LGPL I can't use it and I suspect others will have the same problem. GPL for a library you want everyone to use doesn't make much sense. Try to focus on the project, not on technical (legal) problems involved in making it part of GNOME. It's their job to relicense properly before becoming a part of desktop. If they fail then I believe all of us will be -1. It's not required to be LGPL to enter the desktop, it's only to enter the plateform. I'm not proposing libempathy(-gtk) to the plateform and that won't happen soon. Xavier. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.24
Le mercredi 26 mars 2008 à 19:32 +0100, Sven Herzberg a écrit : Hi, Am Mittwoch, den 26.03.2008, 19:13 +0100 schrieb Xavier Claessens: Did I forgot something? Xavier Claessens. Missing password security. And absolute no-go in the current shape. Regards, Sven Right, I'll take a look at MissionControl's code to see if it's possible to work around that and use gnome-keyring without waiting for the new MC spec. Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Module proposal: Empathy for GNOME 2.24
* Proposal: Include Empathy in GNOME 2.24 desktop. * Purpose: Empathy [1] consists of a rich set of reusable instant messaging widgets, and a GNOME client using those widgets. It uses Telepathy and Nokia's Mission Control, and reuses Gossip's UI. The main goal is to permit desktop integration by providing libempathy and libempathy-gtk libraries. libempathy-gtk is a set of powerful widgets that can be embeded into any GNOME application. * Dependencies: glib-2.0 = 2.16.0 gconf-2.0 = 1.2.0 libxml-2.0 libtelepathy = 0.3.2 telepathy-glib = 0.7.3 libmissioncontrol = 4.53 gtk+-2.0 = 2.12.0 libglade-2.0 = 2.0.0 libebook-1.2 libpanelapplet-2.0 = 2.10.0 * Resource usage: Already using GNOME FTP, GNOME SVN and GNOME bugzilla. * Adoption: It is packaged at least for debian, ubuntu, mandriva, gentoo and fedora. There is patches for Totem and nautilus-send-to [2] to make use of libempathy(-gtk). There is a gtetrinet branch which uses libempathy-gtk to play with contacts. There is also a python plugin for epiphany using pyempathygtk [3]. Empathy is also used by Soylent [4]. * GNOME-ness: The community reports bugs in GNOME bugzilla and attach patches, I review and commit in GNOME's SVN. GNOME translation teams are already translating empathy. The UI is build with GNOME spirit in mind, empathy inherit from Gossip's excellent UI. * Miscellaneous: - Audio/Video support is still disabled by default but most problems comes from other telepathy layers and are being worked. I'm pretty sure it will be enabled soon. That means Empathy will be able to do audio/video calls over SIP and Jabber, MSN will surely come at some point too. Empathy is the only program capable of that AFAIK. - libtelepathy is now deprecated, empathy is moving to telepathy-glib. If we finish the transition we'll drop libtelepathy dependency. - Empathy's part for file-transfer is almost done, but the telepathy spec is likely to change soon. I hope it will be ready in time for 2.24. - API is still not documented and likely to change, I know this sucks. - There is no user documentation yet, I'll write an email to ask documentation team to write one base on Gossip's doc. - Empathy was proposed for GNOME 2.22 but got rejected because it was not considered stable/mature enough. Lots is already fixed and I hope to fix more during the 6 months coming. Help from the community is of course welcome! Thanks, Xavier Claessens. [1] http://live.gnome.org/Empathy [2] http://www.barisione.org/blog.html/p=100 [3] http://blog.senko.net/2007/07/19/emphatic-epiphany [4] http://live.gnome.org/Soylent ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.24
Le mardi 25 mars 2008 à 12:02 +0100, Patryk Zawadzki a écrit : * GNOME-ness: The community reports bugs in GNOME bugzilla and attach patches, I review and commit in GNOME's SVN. GNOME translation teams are already translating empathy. The UI is build with GNOME spirit in mind, empathy inherit from Gossip's excellent UI. The user icons cry for a replacement. I'd suggest contacting either the Gajim team and asking them for their default iconset or contacting the Tango crew. I know this might sound offtopic but causes a major usability regression when former Gajim/Pidgin/whatever users are confronted with Empathy's interface. It's only a matter of taste, some users like you are complaining, others used to gossip prefer not changing them... My hope is to move most of IM icons to the icon naming spec so user can change them just by changing their desktop icon theme. I'd also ask you to release tarballs often during the next 6 months so it's easy to judge if the project meets the expectations and if there is enough momentum to make it fully usable for 2.24. Empathy 0.21.x were released following the GNOME schedule, I'm planning to do the same with 0.23.x. And if empathy get accepted in the desktop I'll follow the freezes and release under the version 2.23.x. (Not a core GNOME member but +1, GNOME really needs a unified IM experience and deserves something better than libpurple) Thanks for the +1. In fact empathy can use libpurple to connect all protocols implemented in it (thx to telepathy-haze)! but for MSN, Jabber, IRC and SIP we have 'native' implementations for telepathy. Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.24
Le mardi 25 mars 2008 à 07:01 -0500, Travis Watkins a écrit : Did anything ever happen with the license issues for the libraries? They should be LGPL. Nothing changed. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.24
Le mardi 25 mars 2008 à 16:30 +0100, Mathias Hasselmann a écrit : Telepathy and Empathy look very promising, but Telepathy doesn't support buddy lists for IRC (and SIP) yet. Not having buddy lists for IRC would be a major regression for my use patterns of IRC. So personally I don't consider Empathy mature enough until Robert McQueen has finished his work on IRC buddy lists. Ciao, Mathias It is really not an essential feature in my opinion. Empathy is planning to split chatrooms into a dedicated application looking like xchat-gnome but based on libempathy-gtk, it could be a cool SoC project... Even if it's not done for 2.24 that's something we can do later. Xavier. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.24
Le mardi 25 mars 2008 à 09:26 -0400, Hubert Figuiere a écrit : On Tue, 2008-03-25 at 11:50 +0100, Xavier Claessens wrote: libmissioncontrol = 4.53 libmissioncontrol is LGPLv2 only. This is a problem as it prevent Gnome to ever move to (L)GPLv3. That's a -1 solely because of that. This is unlikely Nokia will relicence it. However, Collabora is working on a new dbus spec to access MissionControl, so we won't link on a library anymore, the needed wrapper will be move to telepathy-glib. I can't say that I'll drop libmissioncontrol dep for 2.24, but it will happen for sure one day... Xavier. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.24
Le mardi 25 mars 2008 à 17:27 +0100, Sven Herzberg a écrit : Hi, Are passwords still stored in unencrypted files? That's also a -1. Regards, Sven Sadly Empathy still put password in gconf. That will change when we'll replace MC. If new MC isn't ready in time I'll try to hack a bit MC to use gnome-keyring. I think that's something that will be solved before 2.24. Xavier. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.24
Le mardi 25 mars 2008 à 17:20 +0100, Mathias Hasselmann a écrit : Am Dienstag, den 25.03.2008, 15:45 + schrieb Alberto Ruiz: 2008/3/25, Mathias Hasselmann [EMAIL PROTECTED]: Hi Mathias, Telepathy and Empathy look very promising, but Telepathy doesn't support buddy lists for IRC (and SIP) yet. Not having buddy lists for IRC would be a major regression for my use patterns of IRC. Do we have any official IRC support on GNOME? IMHO there shouldn't be an issue in having empathy for 2.24 and then have IRC support for 2.26. We don't have any IRC support among the current desktop suite, so I can't see why is this a regression. Currently Pidgin, XChat and XChat-GNOME provide IRC UIs. All those applications have buddy lists for IRC. Please define what you mean by irc buddy list. I saw that pidgin is able to add an IRC contact into the main contact list, but AFAIK xchat(-gnome) can't do similar things. Xavier. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.24
Le mardi 25 mars 2008 à 19:21 +0100, Xavier Bestel a écrit : On mar, 2008-03-25 at 17:15 +0100, Xavier Claessens wrote: Le mardi 25 mars 2008 à 09:26 -0400, Hubert Figuiere a écrit : On Tue, 2008-03-25 at 11:50 +0100, Xavier Claessens wrote: libmissioncontrol = 4.53 libmissioncontrol is LGPLv2 only. This is a problem as it prevent Gnome to ever move to (L)GPLv3. That's a -1 solely because of that. This is unlikely Nokia will relicence it. However, Collabora is working on a new dbus spec to access MissionControl, so we won't link on a library anymore, the needed wrapper will be move to telepathy-glib. I'm not sure just working around the licence via dbus would work. That's the idea of the new MC spec, but it's not yet finalized nor implemented. Xav Xav :D ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.24
Le mardi 25 mars 2008 à 19:51 +, Ross Burton a écrit : On Tue, 2008-03-25 at 20:48 +0100, Mathias Hasselmann wrote: Just from Empathy, or also Telepathy? What's the rationale behind this decision? Why should we waste resources for such a crippled IM framework on our machines? I have to admit that I went from ±0 to -2 during this discussion. From Empathy, not from Telepathy. As you say, removing group chat from telepathy would be crippling it and totally stupid. Well, it won't be removed, it will be moved from the main UI to a dedicated UI. 99% of the code of the client is in libempathy and libempathy-gtk. Xav. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Empathy branched for 2.22
I branched Empathy for GNOME 2.22, HEAD is for 2.23 now. Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: State of gvfs in Gnome 2.21
2008/1/23, Vincent Untz [EMAIL PROTECTED]: Le mercredi 23 janvier 2008, à 12:17 +0100, Alexander Larsson a écrit : These are the major regressions in the nautilus stack, but there are also other uses of gnome-vfs in the desktop. Like the trash applet (being worked on i believe) and the panel menus. I don't know the status of these atm. Could people fill in the current status? I want to port Empathy to gio but I need a replacement for gnome_vfs_open_url(), I know it's doable with the API but IIRC some were not implemented last time I tried. The filetransfer branch of Empathy uses gio :D ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: empathy
Le mercredi 26 décembre 2007 à 12:18 +0100, Steve Frécinaux a écrit : On Sat, 2007-12-22 at 14:25 +0100, Guillaume Desmottes wrote: c) A user friendly audio/video client (currently using Jingle and SIP but that could be extended to MSN at some point). Out of curiosity, what's the current level of SIP support within empathy/telepathy ? telepathy-sofiasip should work pretty well, it's shipped in Nokia's N810. I never tested it using empathy but it should work as good/bad as jingle. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: empathy
Le lundi 24 décembre 2007 à 12:48 +, Gustavo J. A. M. Carneiro a écrit : I would just like to say that I am concerned about telepathy storing unencrypted passwords in GConf instead of GnomeKeyring. GNOME modules should be taking security more seriously, IMHO. It is not empathy's responsibility to store account parameters, MissionControl does that job but unfortunately it does not uses gnome keyring :( On Thu, 2007-12-20 at 04:52 +0100, Vincent Untz wrote: Homepage: http://live.gnome.org/Empathy svn/git/bzr/...: http://svn.gnome.org/viewcvs/empathy/ Proposal on d-d-l: http://mail.gnome.org/archives/desktop-devel-list/2007-September/msg00301.html Short description: == Empathy consists of a rich set of reusable instant messaging widgets, and a GNOME client using those widgets. It uses Telepathy and Nokia's Mission Control, and reuses Gossip's UI. The main goal is to permit desktop integration by providing libempathy and libempathy-gtk libraries. libempathy-gtk is a set of powerful widgets that can be embeded into any GNOME application. Requires new external dependencies: === libtelepathy, telepathy-glib, libmissioncontrol (libtelepathy will go away at some point in the future) Summary so far: === + a few -1 from people thinking it's useless duplication of pidgin/ekiga/etc. work or not wanting to use telepathy + some +1 from people thinking it's going the right way + questions about stability + questions about feature set that might not be complete yet + API documentation needed to be written (I don't know the current status) + no API stability guarantee yet + current license of the libraries is GPL [context: if the libraries are proposed for the platform later, they will need to be LGPL] Xavier can probably send an update about the feature set, the API doc status, and the license. Vincent ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: empathy
On jeu, 2007-12-20 at 04:52 +0100, Vincent Untz wrote: Homepage: http://live.gnome.org/Empathy svn/git/bzr/...: http://svn.gnome.org/viewcvs/empathy/ Proposal on d-d-l: http://mail.gnome.org/archives/desktop-devel-list/2007-September/msg00301.html Short description: == Empathy consists of a rich set of reusable instant messaging widgets, and a GNOME client using those widgets. It uses Telepathy and Nokia's Mission Control, and reuses Gossip's UI. The main goal is to permit desktop integration by providing libempathy and libempathy-gtk libraries. libempathy-gtk is a set of powerful widgets that can be embeded into any GNOME application. Requires new external dependencies: === libtelepathy, telepathy-glib, libmissioncontrol (libtelepathy will go away at some point in the future) Summary so far: === + a few -1 from people thinking it's useless duplication of pidgin/ekiga/etc. work or not wanting to use telepathy + some +1 from people thinking it's going the right way + questions about stability + questions about feature set that might not be complete yet + API documentation needed to be written (I don't know the current status) + no API stability guarantee yet + current license of the libraries is GPL [context: if the libraries are proposed for the platform later, they will need to be LGPL] Xavier can probably send an update about the feature set, the API doc status, and the license. I changed license to LGPL for modules I wrote myself or for Collabora. For the rest I need Gossip devs's permission. About feature set I think we have most needed stuff. VoIP is now merged in trunk but disabled by default at build-time because it still needs some love. I doubt File transfer will be ready in time, the code is ready but it needs to be reviewed: Telepathy spec is not yet approved. API is still not documented and not stable. We are working on a new MissionControl spec, when it will be ready empathy will use it and surely that will break the API again. I'm not proposing libempathy and libempathy-gtk for the platform, I propose Empathy as an IM client for the desktop so I think the API don't have to be stable. Of course I agree it's better to have a stable API for other programs that could use empathy's libraries but it's still to early to guarantee that. Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Roadmap - Information requests for 2.22 sent!
Le mercredi 03 octobre 2007 à 02:52 +0300, Lucas Rocha a écrit : Hi all, As part of our roadmap process, we've sent the roadmap information requests to all module maintainers/developers. If you are a maintainer/developer of a GNOME official module and haven't received the cited message, just let us know about which modules we've missed. I'm maintaining Empathy, proposed for GNOME 2.22, should I write a roadmap too? Thanks, Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.22
Le jeudi 27 septembre 2007 à 00:48 +0200, Sven Herzberg a écrit : Xavier Claessens wrote: * Purpose: Empathy [1] consists of a rich set of reusable instant messaging widgets, and a GNOME client using those widgets. It uses Telepathy and Nokia's Mission Control, and reuses Gossip's UI. The main goal is to permit desktop integration by providing libempathy and libempathy-gtk libraries. libempathy-gtk is a set of powerful widgets that can be embeded into any GNOME application. Next question: consistency with the platform The GNOME platform uses LGPL as the license of choice to provide ISVs with a powerful stack that anyone can use - even to build proprietary software. You say, you took code from gossip - which is GPL. How do you plan to mess with this? Introduce a GPL-only library into the platform? Get the code relicensed? I really think that this needs to be solved before we even add empathy as a blessed dependency. I don't propose those libs for the platform, only for the desktop atm, we can even let libempathy(-gtk) as external dep and accept the client in the desktop. Right, libempathy and libemapthy-gtk are GPL because it contains code from Gossip. libempathy mostly contains trivial code from gossip, the rest is rewritten by me or some collabora workers who are 100% OK to relicence, so it shouldn't be a problem to relicence libempathy to LGPL. libempathy-gtk is more a problem since lots of non-trivial code is written by Gossip developers who doesn't seems to agree to relicence to LGPL... I agree the licence will be sooner or later a problem, I see no other solution than convincing Gossip developers to accept LGPL. Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.22
Le jeudi 27 septembre 2007 à 10:07 +0200, Mikael Hallendal a écrit : 27 sep 2007 kl. 09.07 skrev Xavier Claessens: Hi, Right, libempathy and libemapthy-gtk are GPL because it contains code from Gossip. libempathy mostly contains trivial code from gossip, the rest is rewritten by me or some collabora workers who are 100% OK to relicence, so it shouldn't be a problem to relicence libempathy to LGPL. libempathy-gtk is more a problem since lots of non-trivial code is written by Gossip developers who doesn't seems to agree to relicence to LGPL... I'm getting slightly tired of you Xavier, again. What are you basing this on? I for one haven't been asked at all regarding this topic. I asked Martyn's opinion long ago, I know he is not the only person to decide but he wasn't for the relicencing. Xavier. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.22
Le jeudi 27 septembre 2007 à 10:03 +0100, Martyn Russell a écrit : Xavier Claessens wrote: Le jeudi 27 septembre 2007 à 10:07 +0200, Mikael Hallendal a écrit : 27 sep 2007 kl. 09.07 skrev Xavier Claessens: Hi, Hi, Right, libempathy and libemapthy-gtk are GPL because it contains code from Gossip. libempathy mostly contains trivial code from gossip, the rest is rewritten by me or some collabora workers who are 100% OK to relicence, so it shouldn't be a problem to relicence libempathy to LGPL. libempathy-gtk is more a problem since lots of non-trivial code is written by Gossip developers who doesn't seems to agree to relicence to LGPL... I'm getting slightly tired of you Xavier, again. What are you basing this on? I for one haven't been asked at all regarding this topic. I asked Martyn's opinion long ago, I know he is not the only person to decide but he wasn't for the relicencing. Rob basically summed it up perfectly. I have to say, I agree with Mikael, this is just not true. Empathy looks EXACTLY like Gossip for the most part, most of the widgets have taken years to write. To say that the code you use is trivial is insulting. You got me completely wrong! I said libempathy-gtk contains lots of NON-Trivial code from Gossip. What I said is libempathy (the non-gui part) contains very few code from Gossip, what remains from Gossip in libempathy is trivial things. Mikael, Richard and I (not to forget the countless others supplying patches) have spent a lot of time writing these widgets and the supporting library (libgossip). All you have done is made a few improvements and put them them on top of another backend. This time it's insulting to me! I didn't made few improvements, I really worked hard and improved lots of things everywhere in the code. I didn't just implemented another backend, I refactored the whole code. Take for example that Empathy contains the half of code lines than Gossip, and no, it's not only because I'm using external libs like MissionControl, I removed all code duplication there is in Gossip. Xavier. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.22
Le jeudi 27 septembre 2007 à 15:48 +0200, Mikael Hallendal a écrit : 27 sep 2007 kl. 15.32 skrev Luis Villa: Hi, On 9/27/07, Andrew Cowie [EMAIL PROTECTED] wrote: On Thu, 2007-09-27 at 10:03 +0100, Martyn Russell wrote: I wouldn't re-license it [there is tons of both context and history here, which the rest of this thread covers. On the topic of licencing, however:] I must admit that as an advocate of software freedom and as someone who works for a firm that releases its work under the GPL, I am not adverse to the idea of a GNOME library being licenced under the GPL only. I realize full well that there is a certain fraction of the wider universe of people who use the GNOME platform who are using it under the pragmatic terms of the LGPL to write their proprietary software. Some of those companies contribute to our community their IP and their employees' time, and that's fantastic. I hugely respect, however, the expression that has been made by people who wrote software under the GPL that they wish it to remain so licenced. That's their call, and it is effectively final. It is of course their call. And likewise it is the GNOME community's call not to accept libraries licensed as such. We have a very longstanding and very deliberate policy to license our libraries LGPL, and it has served us well. This is not the time to change it, *especially* since we want these libraries to be deeply embedded into all of GNOME, not just some applications. I'm a bit unsure about how useful libempathy-gtk would be for third party applications? Do we have any use cases for this as a library. From the way I suggested at the time of the fork was to make Empathy run on top of Telepathy and create the required applications for integrating with mission control etc. This doesn't require an external library though. For example I can't see the chat dialog widgets to be all that useful to other applications as they should preferably message Empathy to show a chat dialog for a specific user. The same with most of the other widgets, roster widget and possibly vcard/info dialogs excluded. Some examples: - Tracker wants EmpathyChatView to display chat logs found by the indexer. - nautilus-sento uses a widget that inherit from GtkCombobox to select a contact. - Megaphone (atm it's part of Empathy tarball but it can change) uses EmpathyContactListView to show the contact list. - Megaphone uses the contact information window from libempathy-gtk But I agree that many widgets won't be used in third party applications and I don't know if there is non-GPL application interested by using empathy widgets. Best Regards, Mikael Hallendal Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.22
Some more details: * About API stability: I can't promose stability yet, there is things I know I will change in the future. I think API stability is not requiered for GNOME desktop. * About API documentation: It's not written yet and I designed the API alone so I think I'm the only one capable to write the doc... so it will take time and I can't promise it will be 100% covered in time for GNOME 2.22, but I'll start to cover most important parts ASAP. * About a11y: I'm not an expert at all for that kind of thing, I would like to have feedback from more experienced users to know if it's correct or if there is things to change. Btw, I got Voice+Video more or less working yesterday, I opened a branch with the code: http://svn.gnome.org/viewcvs/empathy/branches/EMPATHY_VOIP/ Have a nice day, Xavier Claessens. 2007/9/23, Xavier Claessens [EMAIL PROTECTED]: Hi, * Proposal: Include Empathy in GNOME 2.22 desktop. * Purpose: Empathy [1] consists of a rich set of reusable instant messaging widgets, and a GNOME client using those widgets. It uses Telepathy and Nokia's Mission Control, and reuses Gossip's UI. The main goal is to permit desktop integration by providing libempathy and libempathy-gtk libraries. libempathy-gtk is a set of powerful widgets that can be embeded into any GNOME application. * Dependencies: glib-2.0 = 2.14.0 gconf-2.0 = 1.2.0 libxml-2.0 gnome-vfs-2.0 libtelepathy = 0.0.57 libmissioncontrol = 4.33 gtk+-2.0 = 2.12.0 libglade-2.0 = 2.0.0 libgnomeui-2.0 libebook-1.2 libpanelapplet-2.0 = 2.10.0 * Resource usage: Already using GNOME FTP, GNOME SVN and GNOME bugzilla. * Adoption: It is packaged at least for debian, ubuntu, mandriva, gentoo and fedora. It is used by Intel for the moblin [2] platform. There is patches for Totem and nautilus-send-to [3] to make use of libempathy(-gtk). Someone was working on integration in gtetrinet but I don't know the status of that work. There is also an epiphany plugin [4]. Work was being done for GSoC to integrate Empathy into Jockosher [5]. Empathy is also used by Soylent [6]. * GNOME-ness: The community reports bugs in GNOME bugzilla and attach patches, I review and commit in GNOME's SVN. Some i18n teams already started to commit translations. I take care of usability thanks to loads of usability bugs opened by Vincent Untz. User documentation is not started yet, I guess we can pick gossip's doc and adapt it for Empathy since the UI is almost the same. * Miscellaneous: - There is patches to support File Transfer, Voice and Video. I think it will be ready before GNOME 2.22 feature freeze. - Empathy is still a young project with some bugs but I'm pretty sure we can fix them in time for GNOME 2.22. - At some point we'll have same features than Ekiga which is already in GNOME desktop. The big advantage of Empathy is it uses Telepathy framework which make easy for desktop integration and means we'll have VoIP for all protocols (SIP, MSN, Jabber, etc). Empathy supports all IM features (private chat, chatroom, presence, avatar, alias, etc), not only Voice and Video. Ekiga don't have those advantages. Thanks, Xavier Claessens. [1] http://live.gnome.org/Empathy [2] http://www.moblin.org/projects_chat.html [3] http://www.barisione.org/blog.html/p=100 [4] http://blog.senko.net/2007/07/19/emphatic-epiphany [5] http://blog.mikeasoft.com/2007/05/07/jokosher-soc [6] http://live.gnome.org/Soylent ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.22
2007/9/26, Xavier Claessens [EMAIL PROTECTED]: Some more details: * About API stability: I can't promose stability yet, there is things I know I will change in the future. I think API stability is not requiered for GNOME desktop. * About API documentation: Forgot to say: Of course I'll respect the API/ABI freeze in the schedule. It's not written yet and I designed the API alone so I think I'm the only one capable to write the doc... so it will take time and I can't promise it will be 100% covered in time for GNOME 2.22, but I'll start to cover most important parts ASAP. * About a11y: I'm not an expert at all for that kind of thing, I would like to have feedback from more experienced users to know if it's correct or if there is things to change. Btw, I got Voice+Video more or less working yesterday, I opened a branch with the code: http://svn.gnome.org/viewcvs/empathy/branches/EMPATHY_VOIP/ Have a nice day, Xavier Claessens. 2007/9/23, Xavier Claessens [EMAIL PROTECTED]: Hi, * Proposal: Include Empathy in GNOME 2.22 desktop. * Purpose: Empathy [1] consists of a rich set of reusable instant messaging widgets, and a GNOME client using those widgets. It uses Telepathy and Nokia's Mission Control, and reuses Gossip's UI. The main goal is to permit desktop integration by providing libempathy and libempathy-gtk libraries. libempathy-gtk is a set of powerful widgets that can be embeded into any GNOME application. * Dependencies: glib-2.0 = 2.14.0 gconf-2.0 = 1.2.0 libxml-2.0 gnome-vfs-2.0 libtelepathy = 0.0.57 libmissioncontrol = 4.33 gtk+-2.0 = 2.12.0 libglade-2.0 = 2.0.0 libgnomeui-2.0 libebook-1.2 libpanelapplet-2.0 = 2.10.0 * Resource usage: Already using GNOME FTP, GNOME SVN and GNOME bugzilla. * Adoption: It is packaged at least for debian, ubuntu, mandriva, gentoo and fedora. It is used by Intel for the moblin [2] platform. There is patches for Totem and nautilus-send-to [3] to make use of libempathy(-gtk). Someone was working on integration in gtetrinet but I don't know the status of that work. There is also an epiphany plugin [4]. Work was being done for GSoC to integrate Empathy into Jockosher [5]. Empathy is also used by Soylent [6]. * GNOME-ness: The community reports bugs in GNOME bugzilla and attach patches, I review and commit in GNOME's SVN. Some i18n teams already started to commit translations. I take care of usability thanks to loads of usability bugs opened by Vincent Untz. User documentation is not started yet, I guess we can pick gossip's doc and adapt it for Empathy since the UI is almost the same. * Miscellaneous: - There is patches to support File Transfer, Voice and Video. I think it will be ready before GNOME 2.22 feature freeze. - Empathy is still a young project with some bugs but I'm pretty sure we can fix them in time for GNOME 2.22. - At some point we'll have same features than Ekiga which is already in GNOME desktop. The big advantage of Empathy is it uses Telepathy framework which make easy for desktop integration and means we'll have VoIP for all protocols (SIP, MSN, Jabber, etc). Empathy supports all IM features (private chat, chatroom, presence, avatar, alias, etc), not only Voice and Video. Ekiga don't have those advantages. Thanks, Xavier Claessens. [1] http://live.gnome.org/Empathy [2] http://www.moblin.org/projects_chat.html [3] http://www.barisione.org/blog.html/p=100 [4] http://blog.senko.net/2007/07/19/emphatic-epiphany [5] http://blog.mikeasoft.com/2007/05/07/jokosher-soc [6] http://live.gnome.org/Soylent ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.22
Le dimanche 23 septembre 2007 à 21:54 -0500, Jason D. Clinton a écrit : On 9/23/07, Alex Jones [EMAIL PROTECTED] wrote: Hi Xavier On Sun, 2007-09-23 at 23:19 +0200, Xavier Claessens wrote: Currently GNOME has no IM program at all, Ekiga does only voice and video AFAIK. Surely you haven't forgotten Gossip already. :P FWIW, I'm extremely keen on keeping Gossip going. I personally feel that Telepathy is potentially dangerous to our cause. I mean, great, you can voice-video chat with your MSN friends, but you still need an MSN account. One step forward, two steps back. I've been diving deeper in to the code involved here and the more I see the more I dislike. Xavier, it seems that you implemented gossip-telepathy and then forked Gossip to create Empathy? Can you provide some history for us please? What is going on here? We first started a telepathy backend for Gossip, then more deep work was needed to integrate well telepathy into gossip and Gossip developers refused that, they wanted to keep Gossip a Jabber-only client. So I forked Gossip to make Empathy to be a telepathy-only client. That's all. Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Module proposal: Empathy for GNOME 2.22
Hi, * Proposal: Include Empathy in GNOME 2.22 desktop. * Purpose: Empathy [1] consists of a rich set of reusable instant messaging widgets, and a GNOME client using those widgets. It uses Telepathy and Nokia's Mission Control, and reuses Gossip's UI. The main goal is to permit desktop integration by providing libempathy and libempathy-gtk libraries. libempathy-gtk is a set of powerful widgets that can be embeded into any GNOME application. * Dependencies: glib-2.0 = 2.14.0 gconf-2.0 = 1.2.0 libxml-2.0 gnome-vfs-2.0 libtelepathy = 0.0.57 libmissioncontrol = 4.33 gtk+-2.0 = 2.12.0 libglade-2.0 = 2.0.0 libgnomeui-2.0 libebook-1.2 libpanelapplet-2.0 = 2.10.0 * Resource usage: Already using GNOME FTP, GNOME SVN and GNOME bugzilla. * Adoption: It is packaged at least for debian, ubuntu, mandriva, gentoo and fedora. It is used by Intel for the moblin [2] platform. There is patches for Totem and nautilus-send-to [3] to make use of libempathy(-gtk). Someone was working on integration in gtetrinet but I don't know the status of that work. There is also an epiphany plugin [4]. Work was being done for GSoC to integrate Empathy into Jockosher [5]. Empathy is also used by Soylent [6]. * GNOME-ness: The community reports bugs in GNOME bugzilla and attach patches, I review and commit in GNOME's SVN. Some i18n teams already started to commit translations. I take care of usability thanks to loads of usability bugs opened by Vincent Untz. User documentation is not started yet, I guess we can pick gossip's doc and adapt it for Empathy since the UI is almost the same. * Miscellaneous: - There is patches to support File Transfer, Voice and Video. I think it will be ready before GNOME 2.22 feature freeze. - Empathy is still a young project with some bugs but I'm pretty sure we can fix them in time for GNOME 2.22. - At some point we'll have same features than Ekiga which is already in GNOME desktop. The big advantage of Empathy is it uses Telepathy framework which make easy for desktop integration and means we'll have VoIP for all protocols (SIP, MSN, Jabber, etc). Empathy supports all IM features (private chat, chatroom, presence, avatar, alias, etc), not only Voice and Video. Ekiga don't have those advantages. Thanks, Xavier Claessens. [1] http://live.gnome.org/Empathy [2] http://www.moblin.org/projects_chat.html [3] http://www.barisione.org/blog.html/p=100 [4] http://blog.senko.net/2007/07/19/emphatic-epiphany [5] http://blog.mikeasoft.com/2007/05/07/jokosher-soc [6] http://live.gnome.org/Soylent ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.22
Le dimanche 23 septembre 2007 à 12:16 +0200, Vincent Untz a écrit : Hi Xavier, Le dimanche 23 septembre 2007, à 10:59 +0200, Xavier Claessens a écrit : * Dependencies: glib-2.0 = 2.14.0 gconf-2.0 = 1.2.0 libxml-2.0 gnome-vfs-2.0 libtelepathy = 0.0.57 libmissioncontrol = 4.33 gtk+-2.0 = 2.12.0 libglade-2.0 = 2.0.0 libgnomeui-2.0 libebook-1.2 libpanelapplet-2.0 = 2.10.0 I guess this means you're also proposing libtelepathy and libmissioncontrol as external dependencies? True. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.22
Le dimanche 23 septembre 2007 à 13:24 +0200, Vincent Untz a écrit : Le dimanche 23 septembre 2007, à 10:59 +0200, Xavier Claessens a écrit : - At some point we'll have same features than Ekiga which is already in GNOME desktop. The big advantage of Empathy is it uses Telepathy framework which make easy for desktop integration and means we'll have VoIP for all protocols (SIP, MSN, Jabber, etc). Empathy supports all IM features (private chat, chatroom, presence, avatar, alias, etc), not only Voice and Video. Ekiga don't have those advantages. That's an interesting debate. Will the interface of empathy make it easy to call phones mobiles? I'm not quite sure ekiga and empathy fill the same role. We already have SIP implementation and I think it works on the N800. Empathy just lack of UI for voice/video calls but I'm working on that atm. I'm not sure telepathy-sofiasip and farshight are as complete as ekiga but I'm sure work is being done by nokia/collabora to improve that. I almost never used ekiga myself. Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.22
Le dimanche 23 septembre 2007 à 16:00 -0500, Jason D. Clinton a écrit : -1 Needless duplication of work covered by Pidgin and Ekiga (and, so far, done better). This is a reimplementation of the wheel. If the last two Gnome releases are any indication, we are strapped for resources - taking on new modules that add absolutely nothing features-wise but DO add additional maintenance work doesn't seem like a good idea ... for now ... Maybe in 2.24. I strongly disagree, Empathy do NOT reimplement the wheel! Empathy is not just an IM client like all others, it's an IM framework and is the only project that makes possible for other applications to integrate IM features. I'm currently working on Voice+Video support so Empathy will be the first client to support that for SIP, Jabber, and MSN at some point. For the additional maintenance problem Empathy and Telepathy framework is supported by companies like Collabora, Nokia, OLPC (RH) and Intel and some community guys are starting to submit patches too. And we can even use libpurple (from pidgin) in Empathy thanks to telepathy-haze. Currently GNOME has no IM program at all, Ekiga does only voice and video AFAIK. Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.22
Le dimanche 23 septembre 2007 à 16:56 -0500, Jason D. Clinton a écrit : On 9/23/07, Ross Burton [EMAIL PROTECTED] wrote: On Sun, 2007-09-23 at 16:00 -0500, Jason D. Clinton wrote: Needless duplication of work covered by Pidgin and Ekiga (and, so far, done better). This is a reimplementation of the wheel. Empathy is a UI around an IM platform which totally replaces the single-application model of pidgin, ekiga, gossip and every other IM client. With Empathy I can go online when I login and using the same Jabber connection chat in Empathy, see presence in Evolution, and transfer files in nautilus. I'll be logged into the Jabber server once, and the connection is shared between them. Do these features exist yet or are we considering what Empathy could be at some theoretical point in the future? You talk as though we should evaluate Empathy's potential to replace Ekiga... how do the Ekiga developers feel about this? And can it actually deliver on this claim right now? It is working right now, see links I put in my first email for screenshot/movie of nautilus sending a file using Empathy. My only issues with Empathy are stability and features, but I'm +100 for including Empathy in a future GNOME release. Oh, and Pidgen isn't part of GNOME. It's Pidgin and it's non-inclusion in Gnome is irrelevant. Every single distro ships it as the pre-installed IM client for a desktop install. For better or worse, it's the application filling the IM space at the moment and I don't mind saying that it does a damn good job at this. Why are we trying to compete with them? I disagree, it's important for GNOME to provide modern desktop features, so we definitely need an official IM program that follows GNOME HIGs, release schedule, etc. Distributions can still make other choices, like ubuntu shipping firefox instead of epiphany. So what are we going to gain by including Empathy, other than more maintenance work in a Gnome Project that's strapped for developer time? We gain easy to use IM features all over in the desktop. Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.22
Le dimanche 23 septembre 2007 à 17:31 -0500, Jason D. Clinton a écrit : On 9/23/07, Olav Vitters [EMAIL PROTECTED] wrote: today. Are we going to help Empathy with it's effort to some day offer a point-for-point feature match? That's what we are discussing. I don't believe this is what is meant with joining the GNOME project. It is not that we do a 'oh, lets reassign some persons from $PROJECT to Empathy'. I agree with your statement about developer allocation. But that's not what I mean. Inclusion in the official Gnome suite adds a certain level of additional credibility to a project. And while this is always good for the project in question, in this case, we would publicly be encouraging the fragmentation of the de facto Gnome desktop IM space. Would the benefits of telepathy over libpurple outweigh the damage done to community coherancy? At this point, it seems that it would have a net negative effect on end user experience over the course of the next 2-3 years in the sense that two integratable IM projects would have competing teams of folks working on integrating said applications with the Gnome deskop applications. In practice, this means more work for module maintainers who have to accept patches from two different IM projects. I'm pretty sure there is lots more developers working on the Telepathy stack than on pidgin, maybe it's the other way the fragmentation happens, pidgin developers should stop working on a dead project and contribute to Empathy/Telepathy? Or maybe everybody is free to work on the project he likes... Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.22
Le lundi 24 septembre 2007 à 00:12 +0100, Alex Jones a écrit : Hi Olav On Mon, 2007-09-24 at 00:15 +0200, Olav Vitters wrote: On Sun, Sep 23, 2007 at 11:04:43PM +0100, Alex Jones wrote: FWIW, I'm extremely keen on keeping Gossip going. I personally feel that Telepathy is potentially dangerous to our cause. I mean, great, you can voice-video chat with your MSN friends, but you still need an MSN account. One step forward, two steps back. IMO purposely not supporting something that is in some countries (like mine) widely used will ensure your program will not get used. Make it possible for me to chat. I don't care what method it uses (I prefer Jabber, but if someone is on MSN and doesn't want to use e.g. Google Talk, so be it). If you want to advocate free services, make the free services easier to use and better integrated in the application. We would, but people seem to be more interested in high-fiving each other over abstraction layers that de-value underlying protocols. If a program doesn't allow me to chat with my friends (which is what I primarily want in an IM app), then how do you expect me ever to discover the benefits of a free service? We have legacy transports that provide a basic level of support, but it will always be a balancing act, much like the reverse-engineering work in Telepathy/Farsight. Pissing away free development hours chasing a moving target wild geese just so that we can pretend to be compatible is irrefutably masochistic, and I'd really like it to stop. But when Nokia drives a truck of money up to Collabora's offices, I've no problem there, they can do what they like. Nokia's N800 only supports Jabber and SIP, they don't pay for reverse-engineer proprietary protocols AFAIK... telepathy-butterfly and pymsn (MSN support for Telepathy framework) are 100% community work! Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Desktop/People apps (short-term)
I didn't had time to read the full discussion, here is my vision of what should be done for contact managing in the GNOME desktop (freedesktop ?). We need a daemon that get information about contacts from Mission Control accounts and store it locally somewhere. Actually that job is done by eds-sync (which is not part of empathy), it takes all contacts it sees in any telepathy account, request information like avatar/alias and put those information into eds. If the X-Jabber and X-MSN VCard fields are filled in an evolution contact it can merge information from the msn and jabber telepathy contact into one single eds contact. My plan was to use eds contacts filled by eds-sync in empathy, like that eds-sync makes the merging job for me and I just get one contact object per real person and not per telepathy account. I agree we need some remote storing because the user will fill X-Jabber and X-MSN fields and don't want that to be lost, and want to sync that with other desktops or devices like N800. I also agree that eds does not completely fits all our needs. We have the choice of improving eds a bit or building our new API which is called online-desktop-engine if I understand correctly. I think libempathy is not the right place to do all that magic. Empathy is about IM, not a complete contact book managing. We can do all that magic outside empathy (like eds-sync actually does) and empathy can just get the contact list from online-desktop-engine instead of from telepathy. The only thing empathy needs is some mapping between ode-contact (ode=online desktop engine) and telepathy handle. One ode-contact can have many telepathy handles so we need an api like guint ode_contact_get_jabber_tp_handle(OdeContact*); using empathy, the user should be able to say: that 2 contacts are the same real person so we need an api to tell ode to merge information from 2 contacts both contacts can already represent many telepathy contacts. So we need: OdeContact* ode_merge_contacts (OdeContact*, OdeContact*); I see ODE as a central API to access information about all contacts. If we make that new API we need to port evolution to use that API too, like that evolution can make things like: empathy_new_chat_with_contact (OdeContact*) to reply to an email by IM. and ODE will take care of uploading all information in a remote server to let the user sync adresse book in all kind of devices/desktops. That's my point of view. Xavier Claessens. Le jeudi 26 juillet 2007 à 08:53 -0700, Travis Reitter a écrit : On Wed, 2007-07-25 at 15:42 -0400, Owen Taylor wrote: snip So, I think I agree a lot with the basic premises here. But when I look at: Basic Architecture == [Desktop People Apps] - [Empathy] - [e-d-s] - [Online desktop server] That just doesn't make a lot of sense to me. What the Empathy block here is doing here is merging together data from various sources; not just e-d-s, but also Telepathy, Pidgin, or whatever. I see the online-desktop-server as another of those sources. As such, is there any reason to force it into the VCard mold? VCard itself is kind of a pain, but the upshot is that it's a fairly standard address book entry format. Though I've heard that most implementations abuse its extensibility, so it ends up going down to the lowest-common-denominator. But thinking about things in a more social network sense, again, you're right - if we want to pass along someone's contact information, we should just pass along a Mugshot/Online Desktop ID. Then the person getting the contact information is ensured it stays up-to-date, and the person whose information you're passing even has the option to deny it, which is another benefit. I imagine a model more like: [Desktop Apps] | [ Empathy ] / / \\ / / \\ / / \\ [Telepathy] [e-d-s] [Facebook] [[online-desktop-engine]] | [online-desktop-server] (Utter and total ascii art failure...) Note that the online-desktop component is in fact privileged since it's our primary source of information about how to do the merge and it's also where edits of the merge (the user asserts that two people are the same thing) get stored. So, say you edit your personal information in About Me. Does that mean that it would send the changes to libempathy, and libempathy would filter and mangle and send along the changes as appropriate for e-d-s, Facebook, o-d-e, etc.? That sounds good, since it should be possible to handle new and different sources via plugins. It largely pushes logic and work from e-d-s into libempathy - which isn't necessarily a bad thing, given the flexibility/ease-of-upstreaming-changes in libempathy vs e-d-s. You can then imagine that there is a simplified
Re: Icons for IM programs
2007/5/17, Vincent Untz [EMAIL PROTECTED]: Le jeudi 17 mai 2007, à 17:20 +0200, Xavier Claessens a écrit : Hi, With all new IM clients currently under development I think we should think about some GNOME desktop integration. Here I suggest to move protocols and status icons to gnome-icon-theme, like that we can reuse them in all GNOME applications. Actually applications like pidgin, gossip, empathy, landel and event xchat-gnome, all have almost the same icon set. I think we should build a GNOME icon theme for all IM related icons, like new-message, status-available, etc... We already have smileys and some protocols but I think they should be updated with a more tango-like design. The benefit of moving icons to gnome-icon-theme: 1) avoid data duplication, projects copies icons, for example empathy's icons are stolen from landel or gossip 2) avoid work duplication for the tango-team, for example the new-message icon for xchat-gnome is almost the same for pidgin and for gossip, but AFAIK it has been done from scratch for each project 3) users can change icons by simply install a new icon theme, actually they have to change the whole client... or some clients like pidgin have their own icon theme manager which is a dup of gnome (freedesktop?) icon theme system. I would like hear the opinion of developers from all IM clients and tango artists to see if we can create a common icon set. It probably makes sense to get the icon names in the icon naming specification too. Ok so how can we add them in the icon naming spec ? Who should I contact ? Xavier. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
RE: Icons for IM programs
On ven, 2007-05-18 at 15:43 -0500, Diego Escalante Urrelo wrote: (sorry if double-posted, I had some email forwarding issues) Hellooo :) On 5/18/07, Jaap Haitsma [EMAIL PROTECTED] wrote: I would like hear the opinion of developers from all IM clients and tango artists to see if we can create a common icon set. I agree completely. I can see some applications still wanting to add their own themes for somethings like smileys and status icons, but a theme that fits in with the rest of the desktop would be really nice. Pidgin has already been given a very nice tango icon set by the tango artists. So it could be just a matter to get them in the icon naming spec and putting them in gnome icon theme. They are pretty nice, but I bumped into a problem this days... it's not really serious but it would make a difference in certain circumstances. I was talking with a friend on Yahoo and we started playing with the emoticons of Pidgin. At first we didn't recognize some of the icons because we were used to default Yahoo ones, but after some playing we get used to the tango theme. But then this idea hit us. If the person that I'm IM'ing is using the Yahoo icons (on the official client or in an old Gaim or whatever), how can I tell that the icon I'm seeing/sending means the same in the other guy's screen?. Maybe I send a Weird icon and in the other side it's understood as Holy cow! because of the theme difference. It's not an issue exclusive to Pidgin or a possible gnome-im-icons, I wanted to comment it anyway because it _makes_ a difference sometimes. I think the solution here is to have yahoo icons if it's possible by licences. Like that we can have icon names like face-yahoo-something, face-msn-something, etc... I'm not sure things like that should go to gnome-icon-theme even if it's ok for licences. If licences are a problem we can make a seperate package for yahoo/msn/etc icons like that distributions like ubuntu can have them in multiverse. Xavier. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Icons for IM programs
Hi, With all new IM clients currently under development I think we should think about some GNOME desktop integration. Here I suggest to move protocols and status icons to gnome-icon-theme, like that we can reuse them in all GNOME applications. Actually applications like pidgin, gossip, empathy, landel and event xchat-gnome, all have almost the same icon set. I think we should build a GNOME icon theme for all IM related icons, like new-message, status-available, etc... We already have smileys and some protocols but I think they should be updated with a more tango-like design. The benefit of moving icons to gnome-icon-theme: 1) avoid data duplication, projects copies icons, for example empathy's icons are stolen from landel or gossip 2) avoid work duplication for the tango-team, for example the new-message icon for xchat-gnome is almost the same for pidgin and for gossip, but AFAIK it has been done from scratch for each project 3) users can change icons by simply install a new icon theme, actually they have to change the whole client... or some clients like pidgin have their own icon theme manager which is a dup of gnome (freedesktop?) icon theme system. I would like hear the opinion of developers from all IM clients and tango artists to see if we can create a common icon set. Thanks, Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Cancel session shutdown
On mar, 2006-08-22 at 13:34 -0500, Federico Mena Quintero wrote: On Sun, 2006-08-06 at 09:58 +0200, Xavier Claessens wrote: I'm implementing D-Bus support in xchat/xchat-gnome and here is something I want to do: When the X session is closing and xchat has DCC transfers running I want to be notified and in some cases cancel the session shutdown. What you want is to use GnomeClient (the session manager client). In your handler for the save-yourself signal, call gnome_client_request_interaction(). That function later needs to call gnome_interaction_key_return() to indicate whether it wants to cancel the logout process. Gedit has a good example of how to use this; look in gedit-session.c. Federico Thanks ! that's exactly what I need. 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: Cancel session shutdown
On dim, 2006-08-06 at 16:24 -0400, Havoc Pennington wrote: Xavier Claessens wrote: On dim, 2006-08-06 at 09:55 -0400, Havoc Pennington wrote: Xavier Claessens wrote: Hi, I'm implementing D-Bus support in xchat/xchat-gnome and here is something I want to do: When the X session is closing and xchat has DCC transfers running I want to be notified and in some cases cancel the session shutdown. I'm sure that's some kind of thing possible with some D-Bus methods/signals but I can't find anywhere documentation about that... Can someone point me the good way for such things ? Right now you have to do this with XSMP, gnome-session doesn't have a D-Bus protocol for it. Havoc Thanks ! Is there no protocol yet, or is it a reason to not use D-Bus ? I'm not sure what you mean by implementing D-Bus support ; D-Bus is more a means to an end than an end in itself. I writing a xchat plugin to provide a dbus service. The goal is to have external applications that can talk to xchat and do everything a xchat plugin can. My primary goal isn't session management but since I'm writing D-Bus code in xchat I can also add something for sessions if it's possible using D-Bus. If your goal is to implement session management, then D-Bus isn't used for that right now, XSMP is. GNOME could certainly use D-Bus for it instead, but at the moment it does not. I personally think XSMP should be replaced by a shutdown protocol on D-Bus plus a startup programs folder, since XSMP has lots of nasty complexity that nobody really understands or uses. Ok, thanks. Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Cancel session shutdown
Hi, I'm implementing D-Bus support in xchat/xchat-gnome and here is something I want to do: When the X session is closing and xchat has DCC transfers running I want to be notified and in some cases cancel the session shutdown. I'm sure that's some kind of thing possible with some D-Bus methods/signals but I can't find anywhere documentation about that... Can someone point me the good way for such things ? Thanks, Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
