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
+1 from me IMO having chat / voip and video integrated in the desktop will be killer feature for the GNOME desktop Jaap ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Anjuta for GNOME 2.22 (Development tools)
Le vendredi 21 septembre 2007, à 10:42 +0300, Naba Kumar a écrit : Hi Murray, On Thu, 2007-09-20 at 11:06 +0200, Murray Cumming wrote: I have done what it requests. http://live.gnome.org/TwoPointNineteen/DevelTools You added it to 2.19. You probably meant 2.21. Thanks for pointing it out. I hasted in updating it. But now it is in http://live.gnome.org/TwoPointTwentyone/DevelTools Can you add the name of the maintainers to the page too? Thanks, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cheese for 2.22, realistic?
Le samedi 22 septembre 2007, à 17:42 +0200, daniel g. siegel a écrit : On Sa, 2007-09-22 at 17:13 +0200, Vincent Untz wrote: Le samedi 22 septembre 2007, à 16:38 +0200, daniel g. siegel a écrit : hey! im not shure at all, how to begin this mail.. and im even more unshure if i should propose cheese for 2.22 ;) my biggest concern is the development cycle, which is much faster than the gnome one atm (2 weeks to a month vs. 6 months). anyway, here is my proposal for including cheese in 2.22. I'm not quite sure what you mean about the development cycle. We have lots of unstable release during those 6 months. could you tell me more about that? http://live.gnome.org/TwoPointTwentyone Oh, and see http://live.gnome.org/ReleasePlanning/ModuleProposing if you want to have a complete proposal :-) isnt my proposal complete? http://live.gnome.org/ReleasePlanning/ModuleProposing Everything is in the wiki ;-) Vincent -- Les gens heureux ne sont pas pressés. ___ 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
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? Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: GtkGLExt for GNOME 2.22
Le samedi 22 septembre 2007, à 19:10 +0200, Andreas Røsdal a écrit : On Sat, 22 Sep 2007, Vincent Untz wrote: Note that it's possible that it will get rejected for the platform if it doesn't go in the desktop for at least one cycle, since we're quite strict about the platform. So maybe you should propose it for the desktop first? I'd like to be pragmatic and propose the module to the release set which is the most appropriate. Originally, I didn't think that GtkGLExt should be a Desktop module, because it doesn't provide user functionality. But now I see that other libraries such as GStreamer, gnome-doc-utils and libsoup are included in the Desktop release set as well - Despite being development libraries, and not providing end user functionality. Since GtkGLExt is a development library, and should be part of the infrastructure / development platform for other modules, the developer platform was originally the release set that I thought would be most appropriate. So I'm fine with proposing GtkGLExt as a desktop module, at least for the first development cycle. Generally, more long-term, I think that all development libraries in the desktop release set should be in the developer platform release set, ideally. I've moved your proposal to the desktop set, then. Note that it doesn't make sense to have all libraries in the platform, since not all libraries are interesting as a platform right now (some are unstable, eg, and some might not be useful for other developers). Thanks, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Anjuta for GNOME 2.22 (Development tools)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Vincent! Can you add the name of the maintainers to the page too? Done, though there is only ONE maintainer. Regards, Johannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG9j4W7Dsf+G5b/WsRAig1AJ4zEEVHlJSPGiHgx5isNgd/4hkrVQCfSQEi 40Iv4kKcrn/gdfVEc7L18ik= =AEUY -END PGP SIGNATURE- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: GtkGLExt for GNOME 2.22
Sorry, I forgot to reply to one part of the mail :-) Le samedi 22 septembre 2007, à 19:10 +0200, Andreas Røsdal a écrit : On Sat, 22 Sep 2007, Vincent Untz wrote: Well, it won't be accepted if it's unmaintained. So you should do things the other way around: start maintaining it before it can get accepted. I agree. Should I begin maintaining it in the GNOME infrastructure already now? Any suggestions about how to proceed during this development cycle for a smooth inclusion as a new module during this cycle? :-) I think it makes sense to start maintaining it in the GNOME infrastructure now. Else, you'll get blamed for not doing it before when we'll evaluate all module proposals ;-) As for smooth inclusion, the criteria on [1] should give a good idea of what you should be done. [1] http://live.gnome.org/ReleasePlanning/ModuleProposing Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mercurial - Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
Hi all, In my opinion Mercurial has much of the benefits of GIT but with the ease of use of SVN. We dropped GIT and SVN at my company in favor of Mercurial. In what way is Mercurial simpler to use than Git? Looking quickly at the Mercurial docs it seemed quite similar to Git in terms of complexity. I've found most distributed scm's to be similarly complex (not considering early versions Git and Arch, etc). The complexity of distributed scm's are in the areas where CVS/Svn can't even operate. I think as well that mercurial is very easy to use compared to git, but am not sure about the merge capabilities of Mercurial. I think that git complexity comes from the extension mechanism used by git : none. Basically git is extended by writing shell scripts and perl scripts that create new commands, for example git-svn looks like a completely separate tool, where as bzr-svn for example just integrates into bzr, and any bzr command works on the svn repo as if it was a bzr repo or a bzr branch. git looks like a patchwork from my point of view, it reminds me another very popular and ugly tool commonly used : autotools. Cheers, -- Ali ___ 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: cheese for 2.22, realistic?
On So, 2007-09-23 at 12:16 +0200, Vincent Untz wrote: Le samedi 22 septembre 2007, à 17:42 +0200, daniel g. siegel a écrit : On Sa, 2007-09-22 at 17:13 +0200, Vincent Untz wrote: Le samedi 22 septembre 2007, à 16:38 +0200, daniel g. siegel a écrit : hey! im not shure at all, how to begin this mail.. and im even more unshure if i should propose cheese for 2.22 ;) my biggest concern is the development cycle, which is much faster than the gnome one atm (2 weeks to a month vs. 6 months). anyway, here is my proposal for including cheese in 2.22. I'm not quite sure what you mean about the development cycle. We have lots of unstable release during those 6 months. could you tell me more about that? http://live.gnome.org/TwoPointTwentyone i thought, you would point me to something else ;) the problem i see, is unstable releases... i mean: cheese has many new features at each release and this would be then invisible for the end user, as it is always an unstable release. Oh, and see http://live.gnome.org/ReleasePlanning/ModuleProposing if you want to have a complete proposal :-) isnt my proposal complete? http://live.gnome.org/ReleasePlanning/ModuleProposing Everything is in the wiki ;-) yeah, but what was missing? ;) Vincent -- this mail was sent using 100% recycled electrons daniel g. siegel [EMAIL PROTECTED] http://home.cs.tum.edu/~siegel gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred 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: cheese for 2.22, realistic?
Le dimanche 23 septembre 2007, à 12:32 +0200, daniel g. siegel a écrit : On So, 2007-09-23 at 12:16 +0200, Vincent Untz wrote: Le samedi 22 septembre 2007, à 17:42 +0200, daniel g. siegel a écrit : On Sa, 2007-09-22 at 17:13 +0200, Vincent Untz wrote: Le samedi 22 septembre 2007, à 16:38 +0200, daniel g. siegel a écrit : hey! im not shure at all, how to begin this mail.. and im even more unshure if i should propose cheese for 2.22 ;) my biggest concern is the development cycle, which is much faster than the gnome one atm (2 weeks to a month vs. 6 months). anyway, here is my proposal for including cheese in 2.22. I'm not quite sure what you mean about the development cycle. We have lots of unstable release during those 6 months. could you tell me more about that? http://live.gnome.org/TwoPointTwentyone i thought, you would point me to something else ;) the problem i see, is unstable releases... i mean: cheese has many new features at each release and this would be then invisible for the end user, as it is always an unstable release. Then it works fine during the unstable cycle. You'll have to get used to feature freeze and stable cycle, though. Oh, and see http://live.gnome.org/ReleasePlanning/ModuleProposing if you want to have a complete proposal :-) isnt my proposal complete? http://live.gnome.org/ReleasePlanning/ModuleProposing Everything is in the wiki ;-) yeah, but what was missing? ;) At least jhbuild integration and adding cheese to the list of proposed modules on the wiki. Vincent -- Les gens heureux ne sont pas pressés. ___ 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, à 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. Vincent -- Les gens heureux ne sont pas pressés. ___ 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
Status of gnome-keyring-manager for 2.22
Hi, We've discussed this topic a few times already in the past: both gnome-keyring-manager and seahorse let the user play with the keyring, and so we probably don't need both. I think (but I might be wrong) that the consensus was that we'd deprecate gnome-keyring-manager at some point. Can we do this for 2.22? Is there any feature in gnome-keyring-manager that is not in seahorse? If yes, are those features important for our users? Thanks, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Moving libxml2 and libxslt to external dependencies
Hi, After a quick discussion between Daniel and the release team, the idea of moving libxml2 and libxslt from the platform to external dependencies came up. The rationale behind the idea is that those two libraries are now more like base OS libraries than GNOME libraries: they're shipped on nearly all systems. Also, development of those libraries are not following the GNOME development cycle. It shouldn't change anything, since the API and ABI won't be modified anytime soon anyway, and everything else will continue as usual. AFAICT, the only other impact it could have on GNOME is for libxml++: should it stay in our bindings set or not? What do you all think of this proposal? Vincent -- Les gens heureux ne sont pas pressés. ___ 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
On Sun, 23 Sep 2007 13:41:10 +0200, Xavier Claessens [EMAIL PROTECTED] wrote : 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. As I understand it, libempathy is a set of reusable widgets and leverages on the telepathy framework. That implies that nothing should prevent Ekiga from using libempathy/telepathy at some point in the future when it is stable and and has the necessary features. Today, a lot of people are using Ekiga because it *works now* for the softphone use cases. SIP and H232 (yes people are still using that one) are complicated in the sense that just claiming supporting the specs is not enough. You really have to debug your implementation against the buggy behaviours of the servers that are *already* out there in the real world. In that respect, I think that Ekiga is way more mature today than Empathy. Please correct me if I am wrong here. Empathy/Telepathy does look really promising though and I think the nice thing would be to see some kind of integration work going on at some point. I mean, one could imagine some telepathy-opal initiative to take place where necessary, or seeing Ekiga re-using some libempathy stuff at some point. Cheers, -- Dodji Seketeli http://www.seketeli.org/dodji ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Status of gnome-keyring-manager for 2.22
On 9/23/07, Vincent Untz [EMAIL PROTECTED] wrote: Can we do this for 2.22? Is there any feature in gnome-keyring-manager that is not in seahorse? If yes, are those features important for our users? Finding time to finish implementing g-k-m features will largely depend on how my thesis is going. I think access control lists are the last important feature to migrate before deprecating g-k-m. I'm not sure how many users actively control which applications can read, write or delete each gnome-keyring secret. Cheers, Adam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mercurial - Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
2007/9/23, Ali Sabil [EMAIL PROTECTED]: Hi all, In my opinion Mercurial has much of the benefits of GIT but with the ease of use of SVN. We dropped GIT and SVN at my company in favor of Mercurial. In what way is Mercurial simpler to use than Git? Looking quickly at the Mercurial docs it seemed quite similar to Git in terms of complexity. I've found most distributed scm's to be similarly complex (not considering early versions Git and Arch, etc). The complexity of distributed scm's are in the areas where CVS/Svn can't even operate. I think as well that mercurial is very easy to use compared to git, I don't get this argument, looking at http://www.selenic.com/mercurial/wiki/index.cgi/QuickStart tells me that the basic commands one would use for daily development are almost exactly the same as in git. Am I missing something? but am not sure about the merge capabilities of Mercurial. I think that git complexity comes from the extension mechanism used by git : none. Basically git is extended by writing shell scripts and perl scripts that create new commands Isn't this conflicting a bit with what you just said? Furthermore, you can write your tools with whatever you want; Python, Perl, Ruby etc. With Mericurial extensions you are limited to Python. So you could say that the extension mechanism of git allows more options than Mericurial... for example git-svn looks like a completely separate tool, where as bzr-svn for example just integrates into bzr, and any bzr command works on the svn repo as if it was a bzr repo or a bzr branch. I don't see the big issue with this. git-svn is also only the glue from svn to git, all other work is done on the git repository as usual. git looks like a patchwork from my point of view, it reminds me another very popular and ugly tool commonly used : autotools. I guess this is a case of having the beauty in the eye of the beholder... (not that I'd consider autotools to be too beautiful, mind you) -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Drop crasher reports from 2.16 and before
On Fri, Sep 21, 2007 at 05:50:55PM -0500, Diego Escalante Urrelo wrote: Proposal: Drop crasher reports from 2.16 and before If there are no objects, I plan to implement this around 30 September, this year. -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mercurial - Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
On 9/23/07, Kalle Vahlman [EMAIL PROTECTED] wrote: 2007/9/23, Ali Sabil [EMAIL PROTECTED]: Hi all, In my opinion Mercurial has much of the benefits of GIT but with the ease of use of SVN. We dropped GIT and SVN at my company in favor of Mercurial. In what way is Mercurial simpler to use than Git? Looking quickly at the Mercurial docs it seemed quite similar to Git in terms of complexity. I've found most distributed scm's to be similarly complex (not considering early versions Git and Arch, etc). The complexity of distributed scm's are in the areas where CVS/Svn can't even operate. I think as well that mercurial is very easy to use compared to git, I don't get this argument, looking at http://www.selenic.com/mercurial/wiki/index.cgi/QuickStart tells me that the basic commands one would use for daily development are almost exactly the same as in git. Am I missing something? I am not talking about the command set, I am saying basically, that to use git you need to understand its inner working otherwise you are pretty much lost, that's definitely not the case of Mercurial nor bzr. but am not sure about the merge capabilities of Mercurial. I think that git complexity comes from the extension mechanism used by git : none. Basically git is extended by writing shell scripts and perl scripts that create new commands Isn't this conflicting a bit with what you just said? Furthermore, you can write your tools with whatever you want; Python, Perl, Ruby etc. With Mericurial extensions you are limited to Python. So you could say that the extension mechanism of git allows more options than Mericurial... I don't know if you are serious, but do you really think that Git is extensible ? I would rather say it got a pseudo extension mechanism : scripts that operate on the repository. And btw, it is technically possible to extend bzr and Mercurial using external tools written in other languages that operate on the repository in the same manner as Git. But I would stay away from that : it is just plain ugly. for example git-svn looks like a completely separate tool, where as bzr-svn for example just integrates into bzr, and any bzr command works on the svn repo as if it was a bzr repo or a bzr branch. I don't see the big issue with this. git-svn is also only the glue from svn to git, all other work is done on the git repository as usual. git-svn dcommit ? anyone ? In fact git-svn as a program should not exist in the first place if git had a serious extension mechanism. Please consider trying both bzr (= 0.91) and mercurial, and judge by yourself. -- Ali ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Drop crasher reports from 2.16 and before
+1 from me. :-) Philip On Fri, 2007-09-21 at 17:50 -0500, Diego Escalante Urrelo wrote: Hey everyone, We discussed this last few days on bugsquad list about the following, we didn't find anything negative about it we are letting you know about it, feel free to comment about it. Proposal: Drop crasher reports from 2.16 and before Reasons: 1. They are really old and most of them are answered well yes, try SVN/last-release it [might be] fixed there, or simply ignored. They only make bugzilla noisy, hence making difficult to find useful reports. 2. It is unlikely any new crasher will occur. As we've been triaging these crashers for over a year, the chance of a new 2.16-specific crasher is not worth the amount of time it takes to triage the dupes. You can easily confirm if a crash report is old enough by checking metadata provided by bug-buddy like the distribution (for example Ubuntu 6.10) and of course the version. Greetings! Diego ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list 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
hard-code freeze break request for gnome-mag
Hi, We get some trouble with the composite extension being ignored due a wrong value read from the DISPLAY variable. This wrong value was introduced direct or indirect by bug #427992: http://bugzilla.gnome.org/show_bug.cgi?id=427992 Gustavo give use a solution that was used in gnome-mag, that was to add the following lines: oaf_attribute name=bonobo:environment type=stringv item value=DISPLAY/ /oaf_attribute to the magnifier/GNOME_Magnifier.server file. But I forgot/don't realized that the colorblind-applet was also affected by this, so these lines must also be added to it's server file, without this when the colorblind filter is activated the screen get entirely grey. This a low risk patch with good benefits. Attached is the patch. Thanks, Carlos. Index: colorblind/GNOME_Magnifier_ColorblindApplet.server.in.in === --- colorblind/GNOME_Magnifier_ColorblindApplet.server.in.in (revisão 559) +++ colorblind/GNOME_Magnifier_ColorblindApplet.server.in.in (cópia de trabalho) @@ -6,6 +6,9 @@ item value=IDL:Bonobo/GenericFactory:1.0/ item value=IDL:Bonobo/Unknown:1.0/ /oaf_attribute + oaf_attribute name=bonobo:environment type=stringv + item value=DISPLAY/ + /oaf_attribute oaf_attribute name=name type=string _value=Colorblind applet/ oaf_attribute name=description type=string value=Control the use of image filters for the colorblind/ /oaf_server ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Fwd: How to download the API references pages?]
Hi Diego, Thanks for your kind reply. I found them in my latest gnome distribution release too. Thank you! -Tim On Thu, 2007-09-13 at 16:26 -0500, Diego Escalante Urrelo wrote: On 9/11/07, Tim Miao [EMAIL PROTECTED] wrote: Hi, This is Tim from Sun desktop team. I'm looking for some GNOME2.20 API references pages/packages/tarballs. Would anyone please give me a hint where I could download them all on page http://library.gnome.org/devel/references ? You can install the -doc packages of your distribution and use Devhelp to browse them (or just a browser to open the installed htmls). But now that you mention it, it would be good to have a link to Download this document in l.g.o. Greetings! Diego ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
AT-SPI hard code freeze break request
Hi. This is to request a freeze break on two outstanding patches: http://bugzilla.gnome.org/show_bug.cgi?id=467366 http://bugzilla.gnome.org/show_bug.cgi?id=472301 The first one is a fix to allow new Firefox 3 event types to be caught. As you know, Firefox has it's own schedule, and they could afford major changes now. I think it would be worth putting in that fix so we could interop with FF3 in this next release. The second one is an API conformance bug. We would like to have this in the earliest version possible since it is a small but fairly significant fix. The above is the opinion of Willie Walker and I with Li Yuan's consent. I wish us all a victorious release. Cheers, Eitan. 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: AT-SPI hard code freeze break request
Hi. I am assuming this is the green light to apply the patch of the first bug? Cheers, Eitan. On Sat, 2007-09-15 at 10:20 -0600, Elijah Newren wrote: I really hate hard code freeze break requests of this magnitude, but given your testing and careful explanation...and the fact that new changes in FF are somewhat forcing your hand, here's approval 1 of 2. 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: AT-SPI hard code freeze break request
Thanks for the thumbs up. Committing changes now. On Sat, 2007-09-15 at 23:30 +0200, Vincent Untz wrote: Le samedi 15 septembre 2007, à 10:20 -0600, Elijah Newren a écrit : On 9/15/07, Willie Walker [EMAIL PROTECTED] wrote: Hi All: GNOME 2.20.0 is pyatspi's first official release to the world, so we want to get the API as close to AT-SPI as possible. In addition, we want it to support the impending FF3 event type annotation feature. The patches in question accomplish these goals and have been tested by various members of the AT-SPI, Accerciser, and Orca teams. http://bugzilla.gnome.org/show_bug.cgi?id=467366 is most important because it will allow the new Firefox 3 annotated event types to come through to users of pyatspi (e.g., Dogtail, LDTP, Accerciser, and soon Orca). Without this patch, the annotated Firefox 3 event types do not make it through, breaking any pyatspi client that happens to be listening for the events, whether they are annotated or not. http://bugzilla.gnome.org/show_bug.cgi?id=472301 is important as well because it will allow users of pyatspi to get the expected experience of AT-SPI where the return value of the event handler specifies whether or not to consume a device event. Without this patch, the return value is ignored, breaking with the expected experience of AT-SPI. I really hate hard code freeze break requests of this magnitude, but given your testing and careful explanation...and the fact that new changes in FF are somewhat forcing your hand, here's approval 1 of 2. Thanks for the extended explanation, Willie. Let's get this in. Approval 2 of 2. Vincent 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: AT-SPI hard code freeze break request
Thanks for the thumbs up. Committing changes now. On Sat, 2007-09-15 at 23:30 +0200, Vincent Untz wrote: Le samedi 15 septembre 2007, à 10:20 -0600, Elijah Newren a écrit : On 9/15/07, Willie Walker [EMAIL PROTECTED] wrote: Hi All: GNOME 2.20.0 is pyatspi's first official release to the world, so we want to get the API as close to AT-SPI as possible. In addition, we want it to support the impending FF3 event type annotation feature. The patches in question accomplish these goals and have been tested by various members of the AT-SPI, Accerciser, and Orca teams. http://bugzilla.gnome.org/show_bug.cgi?id=467366 is most important because it will allow the new Firefox 3 annotated event types to come through to users of pyatspi (e.g., Dogtail, LDTP, Accerciser, and soon Orca). Without this patch, the annotated Firefox 3 event types do not make it through, breaking any pyatspi client that happens to be listening for the events, whether they are annotated or not. http://bugzilla.gnome.org/show_bug.cgi?id=472301 is important as well because it will allow users of pyatspi to get the expected experience of AT-SPI where the return value of the event handler specifies whether or not to consume a device event. Without this patch, the return value is ignored, breaking with the expected experience of AT-SPI. I really hate hard code freeze break requests of this magnitude, but given your testing and careful explanation...and the fact that new changes in FF are somewhat forcing your hand, here's approval 1 of 2. Thanks for the extended explanation, Willie. Let's get this in. Approval 2 of 2. Vincent 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
nxlaunch: A new GTK NX client
Heads up for those interested in remote desktop connections: I just committed a GTK NX client called nxlaunch to the freenx svn repository at berlios: http://svn.berlios.de/viewcvs/freenx/ It's not quite finished, but is largely complete, with only a few features and much bug testing now required. Be nice to incorporate it into the Gnome desktop... Right now, the connection details are read from and written to XML files which are compatible with those generated by the proprietary client from NoMachine. I haven't used any Gnome features in the program as yet; it's pure GTK. It has two components - one is the frontend - nxlaunch. nxlaunch forks a new process and execs nxcl - this is a little program which actually negotiates the connection. nxlaunch and nxcl talk to each other via dbus. Both are GPL licenced. nxcl is an evolution of George Wright's nxclientlib, which was developed as a Google Summer of Code project last summer (2006). Screenshots at http://www.esfnet.co.uk/index.php?page=nxlaunch regards, Seb James ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Introducing new GNOME SVN users
I would love to see this. It would be great to see who the new committers are and what they might be working on. Thanks, --Ken On 9/21/07, Olav Vitters [EMAIL PROTECTED] wrote: Within another project[1], we've starting doing self-introductions. This is nice as to notice whenever someone joins the project/mailing list. An introduction usually contains: * The persons name * IRC nick * City/Country (all fields, but especially this one is of course optional) * Affiliation (school/company/..) * What the person wants to help out with * Historical qualifications (just some background info on e.g. GNOME, how they started, knowledge of programming/pcs, ...) * Free for all textfield Whenever a new SVN account is created, I want to suggest that the person introduces themselves on the mailing list. Not sure exactly which one. For big projects, perhaps the projects mailing list. For translators, gnome-i18n or the mailing list specific to their language. Before I add such a suggestion to the new account introduction email, I want to ensure that more people think this is a good idea. Further, I could even perhaps email some mailing list with all new GNOME account creations (not right now, but soon with the new Mango system). But this is perhaps too impersonal (it would contain something like $PERSON with userid $UID joined GNOME to work on $MODULES / $LANG). Anyone agree with me? [1] Bugzilla -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Ken VanDine http://ken.vandine.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Introducing new GNOME SVN users
On 9/21/07, Ken VanDine [EMAIL PROTECTED] wrote: I would love to see this. It would be great to see who the new committers are and what they might be working on. Agreed! In the translation teams for both GNOME, XFCE and Ubuntu, we ask that all volunteers / collaborators to introduce themselves so that people know who they are and what they're doing. Cheers, -- Og B. Maciel [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Keys: D5CFC202 http://www.ogmaciel.com (en_US) http://blog.ogmaciel.com (pt_BR) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Introducing new GNOME SVN users
Le samedi 22 septembre 2007, à 00:18 +0200, Olav Vitters a écrit : Within another project[1], we've starting doing self-introductions. This is nice as to notice whenever someone joins the project/mailing list. An introduction usually contains: * The persons name * IRC nick * City/Country (all fields, but especially this one is of course optional) * Affiliation (school/company/..) * What the person wants to help out with * Historical qualifications (just some background info on e.g. GNOME, how they started, knowledge of programming/pcs, ...) * Free for all textfield Whenever a new SVN account is created, I want to suggest that the person introduces themselves on the mailing list. Not sure exactly which one. For big projects, perhaps the projects mailing list. For translators, gnome-i18n or the mailing list specific to their language. Before I add such a suggestion to the new account introduction email, I want to ensure that more people think this is a good idea. Further, I could even perhaps email some mailing list with all new GNOME account creations (not right now, but soon with the new Mango system). But this is perhaps too impersonal (it would contain something like $PERSON with userid $UID joined GNOME to work on $MODULES / $LANG). Anyone agree with me? Sounds like a great idea! Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Status of gnome-keyring-manager for 2.22
Le dimanche 23 septembre 2007, à 09:03 -0400, Adam Schreiber a écrit : On 9/23/07, Vincent Untz [EMAIL PROTECTED] wrote: Can we do this for 2.22? Is there any feature in gnome-keyring-manager that is not in seahorse? If yes, are those features important for our users? Finding time to finish implementing g-k-m features will largely depend on how my thesis is going. I think access control lists are the last important feature to migrate before deprecating g-k-m. I'm not sure how many users actively control which applications can read, write or delete each gnome-keyring secret. I'd say less than 1% of our users know about this feature :-) And knowing doesn't mean using. My point is that people can use g-k-m even if it's not part of the desktop anymore. It sounds wrong to keep g-k-m in the desktop only because of this feature. [oh, and really, this is not about killing g-k-m, but just removing it from the desktop suite] Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
[PATCH] Fancier launcher animation if compositing manager is running
Hi, I created a patch to bring a bit more bling to the GNOME panel. It uses a ghost-effect animation as laucnher feedback instead of the current expanding square if a compositing manager is running. The patch can be found here: http://bugzilla.gnome.org/show_bug.cgi?id=479562 Regards. Denis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mercurial - Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
2007/9/23, Ali Sabil [EMAIL PROTECTED]: On 9/23/07, Kalle Vahlman [EMAIL PROTECTED] wrote: 2007/9/23, Ali Sabil [EMAIL PROTECTED]: I think as well that mercurial is very easy to use compared to git, I don't get this argument, looking at http://www.selenic.com/mercurial/wiki/index.cgi/QuickStart tells me that the basic commands one would use for daily development are almost exactly the same as in git. Am I missing something? I am not talking about the command set, I am saying basically, that to use git you need to understand its inner working otherwise you are pretty much lost, that's definitely not the case of Mercurial nor bzr. Sorry, but I did get lost while trying Mercurial just now. I can't understand why I need to merge something that I just committed. I mean, I just modified a file, committed the change and then tried to push the committed change to the place I cloned from. The result was a complaint that it would create remote branches and I needed to merge. Merge what to where? Please don't try to tell me that it should be obvious without undestanding its inner working since it's not. You need to learn what it does when you commit (and that is fine with me), please don't pretend you do not. The situation is hardly different with git. but am not sure about the merge capabilities of Mercurial. I think that git complexity comes from the extension mechanism used by git : none. Basically git is extended by writing shell scripts and perl scripts that create new commands Isn't this conflicting a bit with what you just said? Furthermore, you can write your tools with whatever you want; Python, Perl, Ruby etc. With Mericurial extensions you are limited to Python. So you could say that the extension mechanism of git allows more options than Mericurial... I don't know if you are serious, but do you really think that Git is extensible ? I would rather say it got a pseudo extension mechanism : scripts that operate on the repository. I guess we have different meaning for the word then. What do your extensions do, if not operate on the repository? I thought the whole point of extensions is to import, modify or export data to, in and from the repository. And btw, it is technically possible to extend bzr and Mercurial using external tools written in other languages that operate on the repository in the same manner as Git. But I would stay away from that : it is just plain ugly. The reason why it's NOT ugly with git is that git commands are designed to be used that way, while Mercurial and others are not. for example git-svn looks like a completely separate tool, where as bzr-svn for example just integrates into bzr, and any bzr command works on the svn repo as if it was a bzr repo or a bzr branch. I don't see the big issue with this. git-svn is also only the glue from svn to git, all other work is done on the git repository as usual. git-svn dcommit ? anyone ? In fact git-svn as a program should not exist in the first place if git had a serious extension mechanism. Now I'm really lost, so do you mean that git should talk directly to the svn server when committing or..? Because that would naturally negate any benefit from a local repo... How does bzr handle that? Please consider trying both bzr (= 0.91) and mercurial, and judge by yourself. I tried Mercurial and the result was given above. Maybe I'll try bzr later too. -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ 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
-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. On 9/23/07, Xavier Claessens [EMAIL PROTECTED] wrote: 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 ___ 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
+1 On 9/24/07, Jason D. Clinton [EMAIL PROTECTED] wrote: -1 Needless duplication of work covered by Pidgin and Ekiga (and, so far, done better). This is a reimplementation of the wheel. AFAIK Pidgin is not part of the GNOME desktop. 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 ... This brings an interesting question: what are the additional features that Empathy+Telepathy would bring us? -- Felipe Contreras ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Gnome Applets
Greetings, Since bonobo is heading toward deprecation, what is the new way to write Gnome applets? Most of the documentation that's floating around out there is about 2 -5 years old. I'd like to write new tutorial for python applets with the new preferred architecture. Ciao, Benjamin ___ 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
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. 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. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF 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: Module proposal: Empathy for GNOME 2.22
Op zondag 23-09-2007 om 16:00 uur [tijdzone -0500], schreef Jason D. Clinton: Needless duplication of work covered by Pidgin and Ekiga (and, so far, done better). This is a reimplementation of the wheel. Are you serious? Although I have my own gripes with Empathy[1], at least it tries to integrate with GNOME. Pidgin isn't part of GNOME in the first place, but moreover it doesn't even pretend to have any sort of GNOME integration, short from using GTK for its user interface. If Empathy is able to operate in a HIG-compatible notification mode (see [1]), I'm in favour of including it. regards, -- Reinout van Schouwen [1] http://bugzilla.gnome.org/show_bug.cgi?id=467829 ___ 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: Gnome Applets
Hi Benjamin On Sun, 2007-09-23 at 16:17 -0500, Benjamin Gramlich wrote: Greetings, Since bonobo is heading toward deprecation, what is the new way to write Gnome applets? Most of the documentation that's floating around out there is about 2 -5 years old. I'd like to write new tutorial for python applets with the new preferred architecture. Ryan Lortie was rewriting panel stuff, but has moved on to DConf/GSettings lately. From what I understand, panel applets define a service name and an object path, say org.gnome.Rhythmbox and /org/gnome/Rhythmbox/PanelApplet respectively. The object implements the org.gnome.PanelApplet interface, which defines a method for grabbing a socket to use with XEmbed or whatever. You then just need to make sure your service is D-Bus activatable, by including a Service Definition in /usr/share/dbus-1/services. Ryan? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: nxlaunch: A new GTK NX client
Le lundi 17 septembre 2007 à 16:26 +0100, Seb James a écrit : Heads up for those interested in remote desktop connections: I just committed a GTK NX client called nxlaunch to the freenx svn repository at berlios: This sounds quite interesting, but I would have loved to see this work integrated in tsclient instead - unless you are also planning to integrate XDMCP and RDP functionality. Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome Applets
Hi, Le dimanche 23 septembre 2007, à 16:17 -0500, Benjamin Gramlich a écrit : Greetings, Since bonobo is heading toward deprecation, what is the new way to write Gnome applets? Most of the documentation that's floating around out there is about 2 -5 years old. I'd like to write new tutorial for python applets with the new preferred architecture. The current applet architecture still uses bonobo. This will probably change soonish (yes, we - or at least I - have been saying this for quite some time...). We only need someone to step up to take what's good in Ryan's work, finish it and integrate it. I had plans to do this for 2.22, but it's becoming unlikely I'll be able to have enough time to complete this in the 6 next months. I'm trying to stop promising stuff I won't be able to deliver in time ;-) Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome Applets
Where can I find a tarball of Ryan's work? What needs to be done still? ciao, bg ___ 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
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? 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? 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? ___ 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
On Sun, Sep 23, 2007 at 04:56:34PM -0500, Jason D. Clinton wrote: 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? Ehr, you seem to be arguing that people shouldn't start their own projects, but rather join an existing one. IMO you cannot dictate what people do with their time. People will write the same application 5 different times, then again when some new language comes out. Pidgin is just as welcome to propose themselves to be part of the GNOME project. 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? It is a new developer, so I don't see how it is relevant. -- Regards, Olav ___ 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
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. ___ 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
On 9/23/07, Xavier Claessens [EMAIL PROTECTED] wrote: 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. Isn't that exactly what libpurple is which you mention below (which is already stable and implemented)? 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. So why not wait until 2.24 when you have those features? 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. But why is this duplication occuring? Currently GNOME has no IM program at all, Ekiga does only voice and video AFAIK. See my other reply regarding Pidgin's de facto status as the Gnome desktop IM client. Why are you competing with them? ___ 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
On 9/23/07, Reinout van Schouwen [EMAIL PROTECTED] wrote: Op zondag 23-09-2007 om 16:00 uur [tijdzone -0500], schreef Jason D. Clinton: Needless duplication of work covered by Pidgin and Ekiga (and, so far, done better). This is a reimplementation of the wheel. Are you serious? Although I have my own gripes with Empathy[1], at least it tries to integrate with GNOME. Pidgin isn't part of GNOME in the first place, but moreover it doesn't even pretend to have any sort of GNOME integration, short from using GTK for its user interface. I'm completely serious. Pidgin integrates with Gnome (see Evolution contact sharing) and even correctly implements the notification icon that you fault Empathy for getting wrong. Have you actually tried using Pidgin? ___ 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
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. 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? -- Regards, Olav ___ 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
On 9/23/07, Olav Vitters [EMAIL PROTECTED] wrote: On Sun, Sep 23, 2007 at 04:56:34PM -0500, Jason D. Clinton wrote: 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? Ehr, you seem to be arguing that people shouldn't start their own projects, but rather join an existing one. IMO you cannot dictate what people do with their time. People will write the same application 5 different times, then again when some new language comes out. Pidgin is just as welcome to propose themselves to be part of the GNOME project. Said developer is free to do whatever they want with their time. Said developer has asked for project resources to assist in his effort in a competing with an existing project that gives users exactly what they need, 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'm saying it's a bad idea right now. Let's revisit it when it actually has the features proposed. ___ 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
On Sun, Sep 23, 2007 at 05:15:36PM -0500, Jason D. Clinton wrote: On 9/23/07, Olav Vitters [EMAIL PROTECTED] wrote: Ehr, you seem to be arguing that people shouldn't start their own projects, but rather join an existing one. IMO you cannot dictate what people do with their time. People will write the same application 5 different times, then again when some new language comes out. Pidgin is just as welcome to propose themselves to be part of the GNOME project. Said developer is free to do whatever they want with their time. Said Ehr, why just use his name, Xavier? You message seems a bit harsh. developer has asked for project resources to assist in his effort in a competing with an existing project that gives users exactly what they need, No, he asked to be part of the GNOME project. Is is not about competing. 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'm saying it's a bad idea right now. Let's revisit it when it actually has the features proposed. That is the only thing we should be discussing. Does it add value to the GNOME project? I only used it once, so no idea yet. -- Regards, Olav ___ 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
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. ___ 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
On 9/23/07, Xavier Claessens [EMAIL PROTECTED] wrote: 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? I would be very interested to see any evidence to back-up this claim. Such evidence would be enough to sway my opinion if Pidgin is dead as you claim. Or maybe everybody is free to work on the project he likes... We're discussing whether or not to include your project in Gnome, not whether or not you should be allow to develop what you will. ___ 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
Hi, Op maandag 24-09-2007 om 00:19 uur [tijdzone +0200], schreef Xavier Claessens: 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. Not to mention translations! Distributions can still make other choices, like ubuntu shipping firefox instead of epiphany. Indeed. :-[ regards, -- Reinout van Schouwen ___ 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
On Sun, Sep 23, 2007 at 05:31:32PM -0500, Jason D. Clinton wrote: 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. So Pidgin developer should quickly rework it to be only on of UI for telepathy-managed connection. Same thing shoudl Gajim developers do. -- Tomasz TorczFuneral in the morning, IDE hacking [EMAIL PROTECTED]in the afternoon and evening. - Alan Cox ___ 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
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. ___ 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
On 9/23/07, Xavier Claessens [EMAIL PROTECTED] 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. libempathy looks like a very interesting library, unfortunately the documentation (http://library.gnome.org/devel/libempathy/stable/) plain suck. Therefore I'd like to register a very strong -1 vote until libempathy has *excellent* documentation (not adequate, not even good, I want *quality*). The features the library provides looks great, but no docs is a show stopper. -- mvh Björn ___ 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
On Mon, Sep 24, 2007 at 12:12:12AM +0100, Alex Jones wrote: 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. I completely understand if it is not done because you'd rather code than reverse engineer (I'd still use another program.. sorry). -- Regards, Olav ___ 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: Module proposal: Empathy for GNOME 2.22
On Sun, 2007-09-23 at 17:31 -0500, Jason D. Clinton wrote: 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. This isn't a choice between Pidgin in GNOME vs Empathy/Telepathy in GNOME. Pidgin, realistically, is never going to integrate deeply into GNOME - that's just not their focus. Pidgin has to appeal not just to GNOME, but to Windows users and to the KDE people who don't like Kopete. Even if it were to be put into the GNOME stack, I'm not convinced that it's designed such that deep integration would be possible. And the lack of HIG compliance [1], external hosting, etc. make it (I think) questionable whether GNOME would accept its integration even were such an effort to be made. Empathy, on the other hand, /can/ integrate deeply into GNOME, and wants to. And the design of Telepathy makes it possible to do this in a way that is largely agnostic to Empathy, and interoperable with both other IM services and programs. Further, saying 'yes' to Empathy doesn't mean everyone just abandon Pidgin. There was a Summer of Code Project for Pidgin [2] this summer to create a Telepathy connection manager (another of the advantages of Telepathy, mind) using libpurple, with a secondary goal that wasn't started of allowing Pidgin to use Telepathy. And there is the advantage that Telepathy is being used by KDE 4 [3] and is a fd.o project, which means that this stuff should all work in KDE, too. Therefore, I don't think the question should be is Empathy better than Pidgin? which gets us nowhere as long as Pidgin stays on its current course, but is Empathy useful enough to GNOME to include it? Which is another debate entirely, but a far more productive one. 1: http://www.pidgin.im/~seanegan/cgi-bin/pyblosxom.cgi/reducing-tab-size.html 2: http://developer.pidgin.im/wiki/Telepathy 3: http://decibel.kde.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome Applets
Where can I find a tarball of Ryan's work? http://blogs.gnome.org/desrt/2006/08/21/your-domain-lowercaseca-is-expiring/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mercurial - Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
On 9/22/07, Ken VanDine [EMAIL PROTECTED] wrote: I would agree with Sean, mercurial is very powerful yet easy to use. Just my $0.02 Mercurial is written in Python (a plus or minus depending on your viewpoint of patching and third party extensions) and it runs on Windows/Mac/Linux. Last time I checked GIT does not run on Windows without some convoluted Cygwin setup. Sean --Ken On 9/22/07, Sean Kelley [EMAIL PROTECTED] wrote: On 9/16/07, Mikael Hallendal [EMAIL PROTECTED] wrote: 16 sep 2007 kl. 04.40 skrev Curtis Hovey: On Sat, 2007-09-15 at 21:44 -0400, Behdad Esfahbod wrote: On Sun, 2007-09-16 at 01:10 +0200, Ali Sabil wrote: - Keith Packard did a fairly extensive research of which DSCM system to use for xorg and other fd.o projects, from a storage robustness / performance point of view, and he wrote this excellent piece: http://keithp.com/blog/Repository_Formats_Matter.html This document is a year old; projects that are under heavy development like Bazaar are misrepresented. For instance bzr has changed it's repository format, and is much faster that it was a year ago. In fairness, so is Git. It's perceived complexity is to a large part based on people trying it out a long time ago while it is as well being developed and higher level abstractions are added. In my opinion Mercurial has much of the benefits of GIT but with the ease of use of SVN. We dropped GIT and SVN at my company in favor of Mercurial. Sean Cheers, Mikael Hallendal -- Imendio AB, http://www.imendio.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Ken VanDine http://ken.vandine.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mercurial - Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
On 9/22/07, Mikael Hallendal [EMAIL PROTECTED] wrote: 22 sep 2007 kl. 16.05 skrev Sean Kelley: Hi, On 9/16/07, Mikael Hallendal [EMAIL PROTECTED] wrote: 16 sep 2007 kl. 04.40 skrev Curtis Hovey: On Sat, 2007-09-15 at 21:44 -0400, Behdad Esfahbod wrote: On Sun, 2007-09-16 at 01:10 +0200, Ali Sabil wrote: - Keith Packard did a fairly extensive research of which DSCM system to use for xorg and other fd.o projects, from a storage robustness / performance point of view, and he wrote this excellent piece: http://keithp.com/blog/Repository_Formats_Matter.html This document is a year old; projects that are under heavy development like Bazaar are misrepresented. For instance bzr has changed it's repository format, and is much faster that it was a year ago. In fairness, so is Git. It's perceived complexity is to a large part based on people trying it out a long time ago while it is as well being developed and higher level abstractions are added. In my opinion Mercurial has much of the benefits of GIT but with the ease of use of SVN. We dropped GIT and SVN at my company in favor of Mercurial. In what way is Mercurial simpler to use than Git? Looking quickly at the Mercurial docs it seemed quite similar to Git in terms of complexity. I think the complexity in GIT is a result of the fact that the overlay of cogito is no longer maintained and you have to deal with a variety of commands from git-core. You are dealing with a multitude of commands and options that were never really designed for an end-user developer in mind. Should I do x, y, or z? Carl Worth has done a brilliant job at pointing out those deficiencies on the GIT mailing list based in no small part on his experience getting new developers going with GIT for Cairo. I am not saying that one is necessarily the best for everyone. When I looked at SCMs for my company we, like everyone else, opted for Subversion. I instead had our kernel hackers use GIT. I think just having to help half a dozen people use GIT was an incredible burden on our resources. At the same time I did not want to have to support two different SCMs - GIT for the kernel hackers/experienced hackers and SVN for the unwashed masses. I needed something that would not cause cries of anguish and outrage. A lot of my developers also work on Windows desktops. Show me where GIT works on Windows without Cygwin. Mercurial works best for us. Mercurial has been picked up by Mozilla, OpenSolaris, Xine, Alsa, etc: http://www.selenic.com/mercurial/wiki/index.cgi/ProjectsUsingMercurial Like Subversion, Mercurial maintains an online book: http://hgbook.red-bean.com/ I think GIT is not a very user friendly SCM for those coming from other version control systems. It is far too rough around the edges. Will it get better? I am sure over time it will. But I certainly wouldn't impose it on the multitude of Gnome developers who have varying degress of SCM experience from the git go. :-) my 2cents Sean I've found most distributed scm's to be similarly complex (not considering early versions Git and Arch, etc). The complexity of distributed scm's are in the areas where CVS/Svn can't even operate. Cheers, Mikael Hallendal Sean Cheers, Mikael Hallendal -- Imendio AB, http://www.imendio.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Imendio AB, http://www.imendio.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome Applets
I would really like an opportunity to do some work for Gnome, so if someone would be willing to orient me to the project, I'd love to take it on. ciao, bg ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Why have a ChangeLog file if you already have commit messages?
Hi On 9/17/07, Glynn Foster [EMAIL PROTECTED] wrote: Hey, Callum McKenzie wrote: For some modules, like gnome-applets or gnome-games, with lots of small - loosely related - programs inside, the ChangeLog has a finer granularity than the commit message. The ChangeLog provides a coherent story for the sub-module - something the commit messages don't. In some ways its a sign the repository is poorly arranged, but thats what we've got. For some perspective, the OpenSolaris guys use very simple commit messages, but *all* commits contain a bug id which links to all the information you need. Very similar in many ways to a good detailed ChangeLog, but I'm very much of the either/or group - having nothing seems silly to me. We use Jira and have the bug id's in our commits so they can be easily viewed in Jira. Jira allows us the ability to generate our changelogs with a close tie-in to features/bugs/tasks with a direct link to the changesets in the version control. That presumes you create Jira issues for any changes. It is quite nice to be able to view the software product road map in Jira and directly link back to the version control with details on all the files changed. Sean Glynn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.22
On Sun, 2007-09-23 at 17:07 -0500, Jason D. Clinton wrote: See my other reply regarding Pidgin's de facto status as the Gnome desktop IM client. Being a part of GNOME is not just writing an app that happens to use GTK (and don't even talk about the evolution - great way to smash your addressbook). The fact that it is a successful, widely used program doesn't come into it. It's not a GNOME program (in all the meanings that that has, the least of which is has it actually been accepted into GNOME!) and doesn't want to be. So fine. If one or three other groups want to work on capabilities that _will_ integrate properly with the GNOME desktop and allow other apps to use it, then all the better. AfC Sydney -- Andrew Frederick Cowie We are an operations engineering consultancy focusing on strategy, organizational architecture, systems review, and change management procedures: enabling successful use of open source in mission critical enterprises, worldwide. http://www.operationaldynamics.com/ Sydney New York Toronto London 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: Mercurial - Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
On 9/23/07, Sean Kelley [EMAIL PROTECTED] wrote: I think GIT is not a very user friendly SCM for those coming from other version control systems. It is far too rough around the edges. Will it get better? I am sure over time it will. But I certainly wouldn't impose it on the multitude of Gnome developers who have varying degress of SCM experience from the git go. :-) Garmin's massive one-way pulling of source from a ton of projects probably dosen't make for a good test case. There's a number of things about your situatation that are unique and won't apply to those of us maintaining modules. As I understand it from those I know on the inside, you're more-or-less forking what you deem to be stable snapshots of OSS libraries and maintaining your own company-local repositories that only Garmin developers use. The only merging your doing is taking patches from upstream and backporting them to the libraries you guys have decided to use for your hand helds... please correct me if I'm miss-informed. I'm a little skeptical that your experience will apply to anyone else (except perhaps Nokia and Motorola) based on what I know... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Why have a ChangeLog file if you already have commit messages?
Hi, On 9/19/07, Havoc Pennington [EMAIL PROTECTED] wrote: Hi, On 9/18/07, BJörn Lindqvist [EMAIL PROTECTED] wrote: That is simply not true. Checkout KDE (http://websvn.kde.org/trunk/KDE/), Python (http://svn.python.org/view/python/trunk/) or SDL (http://www.libsdl.org/cgi/viewvc.cgi/trunk/) just to take three random projects that uses Subversion without ChangeLogs. They all have excellent and detailed commit messages that explain *why* something is changed. Looking at some of those, it took me about 2 minutes to find plenty of awful messages, some samples quoted *in their entirety* (from KDE and Python): better use Fix some error upgdaded the test program two mime encoding schemes improved test/main program There are also plenty of good ones I saw quickly in the projects you mention. However, even the good ones are kind of haphazard and inconsistently-formatted. I don't know the correlation vs. causation here. Maybe it's just that people who don't like to write down change details also decide not to use ChangeLog. May well have nothing to do with the technology and everything to do with people. In my experience the maintainers of a software project should have a commit log policy and reject changesets that don't conform. Easier said than done, I know. It is of course much easier inside a company for product based software projects -where our maintainers review not only the changes but also the changeset comments before pushing the changes to our stable Mercurial repos from person ones. Sean I have lots of causation *theories*: using different editors in the two cases; having examples of prior log entries to look at while writing ChangeLog; having to do the commit message as an 'interruption' (like a dialog where you 'just click yes'); the format of the ChangeLog encouraging people to write more (something for every file at least). But I can't prove any of these. Maybe none, some, or all of them have some truth. All I'm saying is, I don't see many ChangeLog entries that say Fix some error and nothing else, and I found plenty of svn log messages along those lines in a couple minutes clicking on the repositories you linked to. This is an empirical conclusion. It's not a conclusion about what should be or what is rational. It's a conclusion about what happens in practice. (Obviously I didn't do a scientific study, if someone is that bored, feel free.) I don't know about git; since I don't understand why svn commit messages don't work as well as ChangeLog does, I don't have an understanding of whether git addresses the issue. It does look like cairo's git logs are nice, so it's possible git addresses whatever the key cause of svn log messages sucking might be. However, who knows. I thought what else uses git? and decided to pick on Richard, http://gitweb.freedesktop.org/?p=packagekit.git;a=log I would say this log has many too-short entries in it. So there's another data point. btw, for svn.mugshot.org we don't use ChangeLog, and I think my log messages are generally terrible on there. The bottom line remains, we should write good messages. This can be done with any technology. My personal suspicion is that *some* people who don't want to use ChangeLog secretly don't want to write a log message longer than a few words, which is easier to get away with in an SCM log than ChangeLog. Others avoiding ChangeLog have more noble motivations like the elegance of not having two copies of the data, and they write nice log messages in the SCM - more power to them. Like code indentation style, many policies are fine, as long as you have one that's applied consistently and well. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mercurial - Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
On 9/23/07, Jason D. Clinton [EMAIL PROTECTED] wrote: On 9/23/07, Sean Kelley [EMAIL PROTECTED] wrote: I think GIT is not a very user friendly SCM for those coming from other version control systems. It is far too rough around the edges. Will it get better? I am sure over time it will. But I certainly wouldn't impose it on the multitude of Gnome developers who have varying degress of SCM experience from the git go. :-) I'm a little skeptical that your experience will apply to anyone else (except perhaps Nokia and Motorola) based on what I know... Well, if you have software projects that you create, regardless of whether they are apps or libraries, then that is what I am speaking to. I need an application that do a certain function for a product and that leads to a whole slew of completely new software. This is the where most of the SCM work that deals on a day to day basis with a version control system. If you want to learn more about how companies build embedded software for projects based on the multitude of elements that make up a root filesystem, then you might read up on Scratchbox, OpenEmbedded, or Poky. I am speaking to the former, not the latter which falls under the scope of what I define as more package management to whatever packaging system you are using. It involves very little work with version control. Sean ___ 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
Jason, Motivation for unpaid Free Software development isn't the same as for commercial software. You can't just tell someone which project(s) they get to work on. They will work on which project(s) they think are most interesting and/or important or they'll choose to do something else with their time. Duplication of effort is frustrating, but that's just how this development model works. And it's important to note that Pidgin, Ekiga, and Empathy have different goals and implementations, so it's not like they're all trying to do literally the same things. Thus any perceived duplication of effort isn't as bad as it may seem. -Travis On Sun, 2007-09-23 at 16:00 -0500, Jason D. Clinton wrote: -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. On 9/23/07, Xavier Claessens [EMAIL PROTECTED] wrote: 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 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org
Re: Module proposal: Empathy for GNOME 2.22
I read your message three time but I still can't figure out if you're for or against Empathy in Gnome. On 9/23/07, Andrew Cowie [EMAIL PROTECTED] wrote: On Sun, 2007-09-23 at 17:07 -0500, Jason D. Clinton wrote: See my other reply regarding Pidgin's de facto status as the Gnome desktop IM client. Being a part of GNOME is not just writing an app that happens to use GTK (and don't even talk about the evolution - great way to smash your addressbook). The fact that it is a successful, widely used program doesn't come into it. It's not a GNOME program (in all the meanings that that has, the least of which is has it actually been accepted into GNOME!) and doesn't want to be. So fine. If one or three other groups want to work on capabilities that _will_ integrate properly with the GNOME desktop and allow other apps to use it, then all the better. AfC Sydney -- Andrew Frederick Cowie We are an operations engineering consultancy focusing on strategy, organizational architecture, systems review, and change management procedures: enabling successful use of open source in mission critical enterprises, worldwide. http://www.operationaldynamics.com/ Sydney New York Toronto London ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.22
You appear to have not read the thread. On 9/23/07, Travis Reitter [EMAIL PROTECTED] wrote: Jason, Motivation for unpaid Free Software development isn't the same as for commercial software. You can't just tell someone which project(s) they get to work on. They will work on which project(s) they think are most interesting and/or important or they'll choose to do something else with their time. Duplication of effort is frustrating, but that's just how this development model works. And it's important to note that Pidgin, Ekiga, and Empathy have different goals and implementations, so it's not like they're all trying to do literally the same things. Thus any perceived duplication of effort isn't as bad as it may seem. -Travis On Sun, 2007-09-23 at 16:00 -0500, Jason D. Clinton wrote: -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. On 9/23/07, Xavier Claessens [EMAIL PROTECTED] wrote: 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 ___ 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
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 andvideo 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? ___ 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
As the lead developer of Soylent, I thought I'd add my own opinions based on experience with libempathy(-gtk). Using libempathy(-gtk) as a Telepathy wrapper made it very easy for me to integrate instant messaging into Soylent. I've found the API to be very consistent and thereby easy to use. The underlying Telepathy and Mission Control libraries also seem to be well-designed, and Mission Control in particular makes it easy to delegate work to external applications (eg, I tell Mission Control to open an instant message to username x with my user account y, and it tells Empathy to open the IM window). In other words, libempathy(-gtk), Telepathy, and Mission Control actually *save* me from duplicating effort (contrary to other opinions in this thread). Xavier pointed out the wide adoption of Empathy(/Telepathy/Mission Control) and great programs which build upon them - I think this stack will important in pushing Gnome forward in many interesting new ways. My main concerns right now are libempathy(-gtk)'s API stability and documentation. The API in svn trunk has changed since the last release (0.12), and (as Björn points out) the documentation is basically non-existent. Xavier, could you explain how you plan to address these concerns in time for the Gnome 2.22 release? Thanks, -Travis On Sun, 2007-09-23 at 10:59 +0200, Xavier Claessens wrote: 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 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GNOME Panel++
Hi list What do we want from the next version of GNOME Panel? Do we want to evolve it or just replace the dependency on Bonobo for now? I think that unifying the concept of applets and more heavyweight widgets might be beneficial, unless anyone can think of any good reason why not to. Any GDesklets developers here? Cheers ___ 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
I read the thread - I just responded in general. But let me get a little more specific: From my own perspective, I would describe the three competing applications as: Empathy is a general communications program based around Telepathy, and meant to be well-integrated into Gnome. Ekiga is a video/audio softphone which is already part of the Gnome Desktop, but implements each communication protocol on its own. Pidgin is a popular multi-protocol instant messaging appliation with no intention to integrate deeply with Gnome (let alone become part of the Desktop/Platform). The main benefit here is that Telepathy is a plugin-based general communications stack which has a lot of community and commercial support and in my (and many other peoples') opinion a well-designed framework which is increasingly polished and increasingly-relevant to Gnome. Because Empathy builds on Telepathy, instead of building its own silo, I don't think it's fair to call it a duplication of effort. And I'd say that the Empathy/Telepathy stack is certainly worth inclusion in Gnome when we all decide it's polished enough. -Travis On Sun, 2007-09-23 at 21:37 -0500, Jason D. Clinton wrote: You appear to have not read the thread. On 9/23/07, Travis Reitter [EMAIL PROTECTED] wrote: Jason, Motivation for unpaid Free Software development isn't the same as for commercial software. You can't just tell someone which project(s) they get to work on. They will work on which project(s) they think are most interesting and/or important or they'll choose to do something else with their time. Duplication of effort is frustrating, but that's just how this development model works. And it's important to note that Pidgin, Ekiga, and Empathy have different goals and implementations, so it's not like they're all trying to do literally the same things. Thus any perceived duplication of effort isn't as bad as it may seem. -Travis On Sun, 2007-09-23 at 16:00 -0500, Jason D. Clinton wrote: -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. On 9/23/07, Xavier Claessens [EMAIL PROTECTED] wrote: 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
Re: GNOME Panel++
On 9/24/07, Alex Jones [EMAIL PROTECTED] wrote: Hi list What do we want from the next version of GNOME Panel? Firstly, I think there is a lot of cool panel like implementations floating around GNOME these days. It might be a good time to merge some together before everything drifts too far apart. The following is a random list of things (and applets) that will hopefully converge into what would be me dream gnome panel 2.0 (3.0?) * Check out this screencast [0] of the state of the art with kiba-dock [1] and avant-window-navigator [2]. Look at these for inspiration! * Desrts compositing panel work [3] as a foundation * WebKitGtk + Jackfield [5] as an alternative to plasmoids * Support for mac style menubar, either transparently [6][7] or optionally [8] * Play well with compiz widget support (like screenlets [9]) * Maybe even moonlight could be used here [10] (but no mono, please) * Workspace previews [11] A hypothetical perfect panel would be much similar to current, with the inertial-things-have-mass bling of akamaru physics engine (from kiba-dock), with the reflection and other gui touches from awn (or libawn). There would be support for some of the cool touches in kiba-dock and awn such as stacks, and the ability to change ones dock icon (like you can in awn) Apologies for a large list of links and no offer to help. I put these out there with the hope to excite people and so that I dont forget them should I happen to mysteriously discover I have abundant free time. John [0] http://fusioncast.blogspot.com/2007/09/fusioncast-flash-episode-i.html [1] http://www.kiba-dock.org/ [2] https://launchpad.net/awn [3] http://git.desrt.ca/gitweb/?p=panel.git;a=summary [4] http://live.gnome.org/WebKitGtk [5] http://www.kryogenix.org/code/jackfield/ [6] http://ubuntuforums.org/showthread.php?t=241868 [7] http://bugzilla.gnome.org/show_bug.cgi?id=353076 [8] http://developer.imendio.com/projects/gtk-macosx/menubar [9] http://www.screenlets.org/index.php/Home [10] http://tirania.org/blog/archive/2007/Jun-28.html [11] http://blogs.gnome.org/nigeltao/2007/06/17/p1mp-my-switcher/ Do we want to evolve it or just replace the dependency on Bonobo for now? I think that unifying the concept of applets and more heavyweight widgets might be beneficial, unless anyone can think of any good reason why not to. Any GDesklets developers here? Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.22
On 9/23/07, Travis Reitter [EMAIL PROTECTED] wrote: I read the thread - I just responded in general. But let me get a little more specific: From my own perspective, I would describe the three competing applications as: Empathy is a general communications program based around Telepathy, and meant to be well-integrated into Gnome. ... The main benefit here is that Telepathy is a plugin-based general communications stack which has a lot of community and commercial support and in my (and many other peoples') opinion a well-designed framework which is increasingly polished and increasingly-relevant to Gnome. Because Empathy builds on Telepathy, instead of building its own silo, I don't think it's fair to call it a duplication of effort. And I'd say that the Empathy/Telepathy stack is certainly worth inclusion in Gnome when we all decide it's polished enough. I'm not against Telepathy per se. I'm not sure that Empathy is the right way to get it in to Gnome, though. At least at this moment. Let me summarize the concerns that I see so far: * It appears to be a fork of Gossip and intended to replace Gossip. The Gossip author has stated that Gossip is not dead. Gossip has telepathy support... * It appears to want to replace Ekiga. There appears to be no buy-in from Ekiga developers. * It appears to want to replace the default IM client installed in distros (Pidgin). * Poor documentation status (could be fixed) * It doesn't implement all of the features it lists as its benefits. (maybe could be fixed by 2.22 release) ___ 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
On Mon, 2007-09-24 at 00:10 -0500, Jason D. Clinton wrote: * It appears to be a fork of Gossip and intended to replace Gossip. The Gossip author has stated that Gossip is not dead. Gossip has telepathy support... * It appears to want to replace the default IM client installed in distros (Pidgin). These are not real concerns. Nor pidgin or gossip are part of the GNOME Desktop. I'd be worried if gossip were proposed for inclusion in GNOME, though, but that's not the case. And I'm not even stating these facts hold... which is a different matter, but irrelevant for the discussion ongoing. * It appears to want to replace Ekiga. There appears to be no buy-in from Ekiga developers. * It doesn't implement all of the features it lists as its benefits. (maybe could be fixed by 2.22 release) These could be interesting issues, *if* they are backed up. If you are really against empathy inclusion in 2.22, I'd suggest you to focus in these particular points. Claudio -- Claudio Saavedra [EMAIL PROTECTED] Día del Software Libre, Curicó http://curico.diadelsoftwarelibre.cl ___ 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
On 9/24/07, Jason D. Clinton [EMAIL PROTECTED] wrote: * It appears to be a fork of Gossip and intended to replace Gossip. The Gossip author has stated that Gossip is not dead. Gossip has telepathy support... FYI Telepathy support has been removed from gossip. Gossip is now only focusing on jabber support. * It appears to want to replace Ekiga. There appears to be no buy-in from Ekiga developers. * It appears to want to replace the default IM client installed in distros (Pidgin). If the consensus is that empathy is better I don't see the problem if it would replace other applications. Evince for example replaced gpdf a couple of releases ago. Jaap ___ 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
El lun, 24-09-2007 a las 00:10 -0500, Jason D. Clinton escribió: * It appears to want to replace the default IM client installed in distros (Pidgin). So? Distros are free to package and ship GNOME components however they see fit so long as they comply with any applicable copyright/trademark licensing. Unfortunately, as a good analogy, most tend to ship Firefox or Seamonkey as the default browser instead of Epiphany - Does this mean we should just stop hacking on Epiphany entirely? That would be far counterproductive to GNOME's goal of being a consistent, user-friendly desktop. Besides, replacing components with better alternatives may be a good thing - such as when gpdf was replaced with Evince. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 signature.asc Description: Esta parte del mensaje está firmada digitalmente ___ 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
On 9/24/07, Jaap Haitsma [EMAIL PROTECTED] wrote: * It appears to want to replace Ekiga. There appears to be no buy-in from Ekiga developers. * It appears to want to replace the default IM client installed in distros (Pidgin). If the consensus is that empathy is better I don't see the problem if it would replace other applications. Evince for example replaced gpdf a couple of releases ago. Once again, the tired refrain: maybe someday but it doesn't appear that it can even come close with only 6 months remaining. Maybe it will be ready for 2.24. ___ 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
On 9/24/07, Peter Gordon [EMAIL PROTECTED] wrote: So? Distros are free to package and ship GNOME components however they see fit so long as they comply with any applicable copyright/trademark licensing. Unfortunately, as a good analogy, most tend to ship Firefox or Seamonkey as the default browser instead of Epiphany - Does this mean we should just stop hacking on Epiphany entirely? That would be far counterproductive to GNOME's goal of being a consistent, user-friendly desktop. The critical difference in that analogy is that the thousands and thousands of man-hours spent on Gecko are reused in the Gnome-ification called Epiphany. As Empathy is proposed, all the work in protocol implementation that has come before in the form of Ekiga and Pidgin appears to be thrown out the window. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
