From: Philip V. H. <spa...@fr...> - 2004-11-19 14:46:27
|
Hi there, As we all probably know has the GNOME community committed itself to the keyword "Integration between different desktop application". As a result you can, on a recent GNOME desktop, for example view the appointments you have when you click on the Clock-applet. Another example is the tight integration with GnomeMeeting and the Evolution Addressbook. My opinion is of course that such an integration is a good thing. GAIM, however, does not easily integrate with other desktop applications. There are proposals to improve the situation but it looks like they have not yet been accepted? http://www.chipx86.com/gevolution/ It would, for example, be nice if evolution could query GAIM about the presence of an individual: http://www.gnome.org/bounties/IM.html#127546. on http://bugzilla.gnome.org/show_bug.cgi?id=3D127546 you can find a proposed implementation of such a featurerequest. Another interesting project that might help integration of other desktop application is Galago http://galago.sourceforge.net/news/index.php. My question is .. Where is the current 'idea', the 'concept' of GAIM heading? Are the core GAIM developers interested in this type of integration and cooperation with other applications? And if so, what is the status? I saw, for example, that you need to utilise a gaim-remote commandline tool to make Gaim do some common operations from within another application. My first thought was: "how can that still be true these days?" and "but...there's CORBA and ORBit, no?!" It even looks like it's using manual sockets-code (much like how xmms has remoting?). Wtf? I understand that platform independency is a nice thing. A solution for that, however, is to create platform dependent drivers or interface- implementations. For example.. say the list of available buddies would be a store that is to be accessed using ORBi, or a lot like the evolution-data-server. So it becomes a service. A problem might be that ORBit doesn't work on all platforms. You could, however, make the accessing this data abstract, and provide one implementation that uses XML and another implementation that will connect to an ORBit-server. And perhaps yet another implementation that will connect to some .NET thing on Windows. The advantage would be that any other GNOME desktop application could also connect to that ORBit-server to get information about the current available buddies. Which would in turn ease integration with other GNOME applications. Note that I'd be interested in helping technically. I am not, however, interested in endless discussions about how greate platform indendency is and how impossible it is to support nice things without breaking that platform independency. It's not impossible. Nothing is impossible. And yeah, so what if that means a lot of work? There is time ... Oh and everything that is well written is maintainable. Maintainability is not related to source-quantity per s=C3=A9. My opinion is that it's more rela= ted to source-quality. --=20 Philip Van Hoof, Software Developer @ Cronos home: me at freax dot org gnome: pvanhoof at gnome dot org work: philip dot vanhoof at cronos dot be junk: philip dot vanhoof at gmail dot com http://www.freax.be, http://www.freax.eu.org |
From: Luke S. <lsc...@us...> - 2004-11-19 15:16:02
|
Just some general thoughts, not really ment to be a full reply. genvolution is in our cvs, and has been for ages. a trivial look at the plugins directory in the source code would show that. galago is a project of chipx86's, who you might note is a gaim developer. I'm not sure what plans he has for it really though. I would not mind making available hooks for integration in a freedesktop.org type maner: not tied to a particular desktop. But realistically, I do not see us going out of our way to do so, you might notice that there is some fairly ambitious work going on within gaim right now if you track the mailing list, a second look at preferences, and a new status code base to name the two currently on the table. with limited time & resources, I simply don't see a 3rd push happening unless someone becomes particularly interested in it (hasn't happened so far, and this is hardly the first time desktop integration has been brought up). gaim right now is slowly but surely headed towards a complete split between functionality & ui for said functionality. there have, over the years, been a large number of requests for a qt ui, a native windows ui, and an aqua ui. we'd like to make this more possible. right now adiumx is using our code base as part of the backend for their client, providing macosx users with better access to gaim's protocol implementations that we can provide them ourselves vai the fink installer. that's awesome, and I'd like to see more of that. it is, for me, something more significant than an extention of the signals system already in gaim to make them available over corba or orbit, althought not incompatable with such an idea. luke |
From: Philip V. H. <spa...@fr...> - 2004-11-19 15:43:14
|
On Fri, 2004-11-19 at 10:15 -0500, Luke Schierer wrote: > Just some general thoughts, not really ment to be a full reply. > genvolution is in our cvs, and has been for ages. a trivial look at the > plugins directory in the source code would show that. Aha, okay. I haven't investigated the sourcecode of Gaim, yet. I am more or less coming back from a very busy professional life this year. I haven't yet got much time to learn about the different opensource projects that would normally fascinate me in a such a way that I start reading and investigating it's sourecode. > galago is a project of chipx86's, who you might note is a gaim > developer. I'm not sure what plans he has for it really though. Yes, I noted that while I was reading more about it a few minutes ago. > I would not mind making available hooks for integration in a > freedesktop.org type maner: not tied to a particular desktop. That would also be my suggestion for such hooks. CORBA, however, is not really tied to a particular desktop. > But realistically, I do not see us going out of our way to do so, you might > notice that there is some fairly ambitious work going on within gaim > right now if you track the mailing list, a second look at preferences, > and a new status code base to name the two currently on the table. with > limited time & resources, I simply don't see a 3rd push happening unless > someone becomes particularly interested in it (hasn't happened so far, > and this is hardly the first time desktop integration has been brought > up). Really the first time? I can't rally imagine that nobody ever brought up "desktop integration". It does sound like a much wanted thing!? I'd, for one, would love to see Gaim integrate with GnomeMeeting for video conferencing, the Addressbook for linking Buddies with your contacts and Evolution for presence notification. :-\ > gaim right now is slowly but surely headed towards a complete split > between functionality & ui for said functionality. there have, over the > years, been a large number of requests for a qt ui, a native windows ui, > and an aqua ui. we'd like to make this more possible. right now adiumx > is using our code base as part of the backend for their client, > providing macosx users with better access to gaim's protocol > implementations that we can provide them ourselves vai the fink > installer. that's awesome, and I'd like to see more of that. Sounds reasonable. I understand the importance of separating the functionality and UI. I'd rather do it for stability and maintainability in stead of reusability. Reusability, for me, is the result when utilising of good programming techniques. I'd never, however, make reusability my primary target (unless, of course, for libraries). Nevertheless, however, it does sound like a good idea (and I wish you guys lots of fun in while doing). > it is, for me, something more significant than an extention of the signals system > already in gaim to make them available over corba or orbit, althought > not incompatable with such an idea. Okay. Thanks for bringing me more or less up-to-date with the current situation. Since "desktop integration" would require a push and the willingness of a large percentage of the current core Gaim developers, the only way to get things going is to discuss about it. I am, however, interested in helping technically. But it would be foolish to start this on my own. So I am not. If ever a team gets assembled that wants to proceed in improving the "desktop integration" of Gaim, feel free to contact me. I'd probably join that team. It depends, of course, on my busy-status. -- Philip Van Hoof, Software Developer @ Cronos home: me at freax dot org gnome: pvanhoof at gnome dot org work: philip dot vanhoof at cronos dot be junk: philip dot vanhoof at gmail dot com http://www.freax.be, http://www.freax.eu.org |
From: PUYDT J. <jul...@la...> - 2004-11-19 18:58:28
|
Le vendredi 19 novembre 2004 =E0 16:43 +0100, Philip Van Hoof a =E9crit : > I'd, for one, would love to see Gaim integrate with GnomeMeeting for > video conferencing, Unfortunately there doesn't seem to be much interest for that on that mailing-list (see my recent posts here). Snark on #gnomemeeting |
From: Christian H. <ch...@gn...> - 2004-11-19 19:35:55
|
On Fri, Nov 19, 2004 at 07:58:14PM +0100, PUYDT Julien wrote: > Le vendredi 19 novembre 2004 ? 16:43 +0100, Philip Van Hoof a ?crit : > > I'd, for one, would love to see Gaim integrate with GnomeMeeting for > > video conferencing, >=20 > Unfortunately there doesn't seem to be much interest for that on that > mailing-list (see my recent posts here). I personally have an interest for it. I think the reason nobody else does is 1) Time, 2) Other priorities, 3) Work on gaim-vv leading to possible confusion that the two have the same goal. Christian --=20 Christian Hammond <> The Galago Project ch...@gn... <> http://galago.sourceforge.net/ |
From: Ethan B. <ebl...@cs...> - 2004-11-19 15:49:57
|
Philip Van Hoof spake unto us the following wisdom: > As we all probably know has the GNOME community committed itself to the > keyword "Integration between different desktop application". For the record, we (the Gaim project) are not part of the GNOME commu- nity any more than we are the KDE community or the XFCE community. Smooth integration with each of these environments would be (and is) awesome, but it is not priority one. As Luke noted, there is a limited amount of talent and effort available to be applied to Gaim, and thus far the portion of it allocated to desktop integration has been rela- tively small. > As a result you can, on a recent GNOME desktop, for example view the > appointments you have when you click on the Clock-applet. Another > example is the tight integration with GnomeMeeting and the Evolution > Addressbook. >=20 > My opinion is of course that such an integration is a good thing. Yeah, it's great if you care about gnomemeeting, evolution, or the gnome clock applet. > GAIM, however, does not easily integrate with other desktop > applications. There are proposals to improve the situation but it looks > like they have not yet been accepted? http://www.chipx86.com/gevolution/ This is part of the regular gaim distribution and has been for ages. I'm not sure why you think it isn't. > Where is the current 'idea', the 'concept' of GAIM heading? Are the core > GAIM developers interested in this type of integration and cooperation > with other applications? And if so, what is the status? Sure, we're interested ... but we're not applying a large portion of our time to it, because there are more important problems to solve. A quick browse of the gaim-devel mailing list would give you an idea of the sort of features and infrastructure we're working on and considering impor- tant these days. > I saw, for example, that you need to utilise a gaim-remote commandline > tool to make Gaim do some common operations from within another > application. My first thought was: "how can that still be true these > days?" and "but...there's CORBA and ORBit, no?!" It even looks like it's > using manual sockets-code (much like how xmms has remoting?). Wtf? What do you mean, "wtf?" My first reaction is to take this as an indi- cation that you don't know jack about IPC or software design, either one; for your benefit I will withold that judgment and give you a chance to explain. How is CORBA in general, or ORBit specifically, a better choice for what gaim-remote does? (I speak not of the specifics of gaim-remote; it has quite fallen by the wayside recently and has a rather anemic functional- ity set -- this is not, however, tied to its method of communication.) Applications have the choice of either invoking gaim-remote to communi- cate with gaim (which, despite your obvious condescension, is a good way to do the communication -- maybe you don't use shell scripts, but some people do), or of communicating with gaim directly via the gaim-remote socket using libgaim-remote. These methods are not worse than CORBA in any way, they are merely different. In fact, knowing what I know about CORBA, I would be inclined to say that they are significantly better in many respects. In short ... what is the problem here? You are aware, are you not, that ORBit communicates via sockets? > I understand that platform independency is a nice thing. A solution for > that, however, is to create platform dependent drivers or interface- > implementations. For example.. say the list of available buddies would > be a store that is to be accessed using ORBi, or a lot like the > evolution-data-server. So it becomes a service. A problem might be that > ORBit doesn't work on all platforms. You could, however, make the > accessing this data abstract, and provide one implementation that uses > XML and another implementation that will connect to an ORBit-server. And > perhaps yet another implementation that will connect to some .NET thing > on Windows. Sure, and we've been working on similar abstractions in other areas of gaim; again, if you bothered to take the time to look at the gaim-devel mailing list, this would become immediately apparent. Again, if you bothered to look at the gaim source you would notice that, like the gevolution plugin, gaim-remote is a plugin shipped alongside gaim -- there is nothing preventing anyone from implementing an alternative com- munication mechanism, and in fact it is already possible to control gaim in quite sophisticated ways via the 'send' functionality of Tk (see http://www.cs.purdue.edu/homes/eblanton/gaim/). The bottom line is that, given the limited amount of developer time and talent available to be applied to gaim, such alternative services have not been a priority. > The advantage would be that any other GNOME desktop application could > also connect to that ORBit-server to get information about the current > available buddies. Which would in turn ease integration with other GNOME > applications. Any gnome application can currently connect to the gaim socket or via the tk send interface. Neither of these are particularly difficult to do. > Note that I'd be interested in helping technically. I am not, however, > interested in endless discussions about how greate platform indendency > is and how impossible it is to support nice things without breaking that > platform independency. It's not impossible. Nothing is impossible. And > yeah, so what if that means a lot of work? There is time ... Oh and > everything that is well written is maintainable. Maintainability is not > related to source-quantity per s=E9. My opinion is that it's more related > to source-quality. It's great that you'd like to help out; feel free to get involved. We, however, are not interested in endless spoutings of how great a given technology is based on ignorance of the alternatives Regarding maintainability ... I'll assume you've never maintained a project of any size. Quality is certainly a factor, but quantity is, as well. Bit rot does happen in any project which is making nontrivial forward progress. Maintainable and affordably maintainable are two entirely different concepts. Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 |
From: Philip V. H. <spa...@fr...> - 2004-11-19 16:25:21
|
On Fri, 2004-11-19 at 10:49 -0500, Ethan Blanton wrote: It looks like I've touched somebodies soul with my dissatisfaction with gaim-remote :-). I am not trying to set the Gaim-house on fire so I will try to stay short and polite in reply. Therefor I didn't reply to all text-blocks. > For the record, we (the Gaim project) are not part of the GNOME commu= - > nity any more than we are the KDE community or the XFCE community= . > Smooth integration with each of these environments would be (and is= ) > awesome, but it is not priority one. As Luke noted, there is a limite= d > amount of talent and effort available to be applied to Gaim, and thu= s > far the portion of it allocated to desktop integration has been rela= - > tively small. Nevertheless are a large amount of the Gaim users, GNOME Desktop users. That doesn't mean that you need to feel "connected" with the GNOME desktop, per s=C3=A9. But I'd also not block suggestions about integratio= n with that same desktop. Unless, of course, those suggestions make the core idea's of the project impossible.=20 But I'll quote Luke: "althought not incompatable with such an idea." > > My opinion is of course that such an integration is a good thing. > Yeah, it's great if you care about gnomemeeting, evolution, or the gnom= e > clock applet. I do :). [CUT] > > I saw, for example, that you need to utilise a gaim-remote commandlin= e > > tool to make Gaim do some common operations from within another > > application. My first thought was: "how can that still be true these > > days?" and "but...there's CORBA and ORBit, no?!" It even looks like i= t's > > using manual sockets-code (much like how xmms has remoting?). Wtf? >=20 > What do you mean, "wtf?" My first reaction is to take this as an indi= - > cation that you don't know jack about IPC or software design, eithe= r > one; for your benefit I will withold that judgment and give you a chanc= e > to explain. > How is CORBA in general, or ORBit specifically, a better choice for wha= t > gaim-remote does? (I speak not of the specifics of gaim-remote; it ha= s > quite fallen by the wayside recently and has a rather anemic functional= - > ity set -- this is not, however, tied to its method of communication.= ) CORBA is a standard. It's understood, supported and maintained by multiple people, multiple programming languages, multiple programming environments and multiple organisations. > Applications have the choice of either invoking gaim-remote to communi= - > cate with gaim (which, despite your obvious condescension, is a good wa= y > to do the communication -- maybe you don't use shell scripts, but som= e > people do), or of communicating with gaim directly via the gaim-remot= e > socket using libgaim-remote. These methods are not worse than CORBA i= n > any way, they are merely different. In fact, knowing what I know abou= t > CORBA, I would be inclined to say that they are significantly better i= n > many respects. > In short ... what is the problem here? You are aware, are you not, tha= t > ORBit communicates via sockets? It's not the only possible transport layer for CORBA. Other than that, as a developer of a large CORBA application in my professional time myself, yes I am aware of that fact. I was not referring to the fact that specifically sockets are used. Because my intentions in my parent posting where to keep my complaint about gaim-remote short as honestly it doesn't matter to much actually, I fear you misunderstood me here. It's the fact that gaim-remote reimplements a large part of what a CORBA implementation provides. it does this, however, in a non standarized way. Luckily you speak of a libgaim-remote, which probably eases all the details for a developer who wants to remotely call procedures in Gaim. Lower in your reply you talk about affordable maintainability. I'd not write my own sockets-code for remote procedure calls if I'd seek affordable maintainability. In that case, I'd for sure go for an existing implementation. Like ORBit-2 for CORBA. Also, the complaint itself is not really point I am trying to make. So lets stop the discussion about gaim-remote. [CUT] > It's great that you'd like to help out; feel free to get involved. We= , > however, are not interested in endless spoutings of how great a give= n > technology is based on ignorance of the alternatives > Regarding maintainability ... I'll assume you've never maintained = a > project of any size. Quality is certainly a factor, but quantity is, a= s > well. Bit rot does happen in any project which is making nontrivia= l > forward progress. Maintainable and affordably maintainable are tw= o > entirely different concepts. I don't have to prove my ability to maintain a large application to you :-). My current employer knows what I am worth. He knows what type of projects he can trust me with. --=20 Philip Van Hoof, Software Developer @ Cronos home: me at freax dot org gnome: pvanhoof at gnome dot org work: philip dot vanhoof at cronos dot be junk: philip dot vanhoof at gmail dot com http://www.freax.be, http://www.freax.eu.org |
From: Felipe C. <fel...@gm...> - 2004-11-19 17:18:16
|
On Fri, 19 Nov 2004 17:25:17 +0100, Philip Van Hoof <spa...@fr...> wrote: > On Fri, 2004-11-19 at 10:49 -0500, Ethan Blanton wrote: > > > In short ... what is the problem here? You are aware, are you not, that > > ORBit communicates via sockets? > > It's not the only possible transport layer for CORBA. Other than that, > as a developer of a large CORBA application in my professional time > myself, yes I am aware of that fact. > > I was not referring to the fact that specifically sockets are used. > > Because my intentions in my parent posting where to keep my complaint > about gaim-remote short as honestly it doesn't matter to much actually, > I fear you misunderstood me here. > > It's the fact that gaim-remote reimplements a large part of what a CORBA > implementation provides. it does this, however, in a non standarized > way. Luckily you speak of a libgaim-remote, which probably eases all the > details for a developer who wants to remotely call procedures in Gaim. > > Lower in your reply you talk about affordable maintainability. I'd not > write my own sockets-code for remote procedure calls if I'd seek > affordable maintainability. In that case, I'd for sure go for an > existing implementation. Like ORBit-2 for CORBA. > > Also, the complaint itself is not really point I am trying to make. > > So lets stop the discussion about gaim-remote. I think I should quickly state what I think of this. Quite simply from what I can see, gaim-remote is not a priority right now; let alone a gaim-remote implementation with CORBA. But that's for us, the current developers, if anyone feels gaim-remote with CORBA is the way to go, go on and code it... after all you seem to feel you are good, you seem to know about CORBA and you feel the need for that. If you don't find enough time and need for it... well, then you may understand us. Frankly I don't think a developers group will from to build that idea, you should get your hands dirty with it. -- Felipe Contreras |
From: Christian H. <ch...@gn...> - 2004-11-19 17:41:58
|
On Fri, Nov 19, 2004 at 03:46:23PM +0100, Philip Van Hoof wrote: >=20 > Hi there, >=20 > As we all probably know has the GNOME community committed itself to the > keyword "Integration between different desktop application". >=20 > As a result you can, on a recent GNOME desktop, for example view the > appointments you have when you click on the Clock-applet. Another > example is the tight integration with GnomeMeeting and the Evolution > Addressbook. Other devleopers have given their input to this, but I'll repeat a few things here. As others have said, we've had other things that we've had to do. Part of the problem is that outside of Gaim, we're all really busy. I personally am getting off work around 8 or 9 at night lately. > My opinion is of course that such an integration is a good thing. Definitely. > GAIM, however, does not easily integrate with other desktop > applications. There are proposals to improve the situation but it looks > like they have not yet been accepted? http://www.chipx86.com/gevolution/ Gevolution is part of Gaim. You just have to click the checkbox in the Plugins list. Whether or not this is on by default is going to be up to distros. > It would, for example, be nice if evolution could query GAIM about the > presence of an individual: http://www.gnome.org/bounties/IM.html#127546. > on http://bugzilla.gnome.org/show_bug.cgi?id=3D127546 you can find a > proposed implementation of such a featurerequest. This is going to happen through Galago. I have some partial Evolution code for this, but it's going to be redone to use their EPlugin API. The current implementation offered on there that I think you're seeing is actually far more complicated than it needs to be. One way or another, it's going to use Galago. The developer of one of those patches is just waiting for a Galago release and some API changes. However, it's still overkill, as he's using his own custom framework and widgets that Galago already provides. I would like Galago to eventually be tied in directly to Gaim. Of course, this would be iff Gaim has been compiled with D-BUS support (more on this in a minute) and when Galago reaches a stability point where I'd feel comfortable doing this. Second best solution would be to bundle the Gaim-Galago plugin with Gaim directly. If this happens, it'll be after Gaim 2.0 stable, as the Gaim-Galago plugin will need some changes for the new status API. Now, for D-BUS.. D-BUS is going to be a standard thing on all distros very soon. It's needed for HAL, it'll be needed for GNOME, and a lot of other apps are moving to it. The downside is, it doesn't work on Windows and some other operating systems. However, if it doesn't work there, it won't exist there, and we'll just handle it through configure checks and #ifdefs, like we always do. Once we have D-BUS support built-in, a lot of things that are currently plugins could then be services. Gaim-Galago could just be some thing listening in a separate process for Gaim D-BUS events. Integrating this would take a bit of work. The easiest way to go about it would be creating a translation layer for signals and API functions. The signals part is easy. We tie into a function, much like loader plugins do, and we get every signal. Then we rebroadcast them. API functions are harder. We would need a way to map the function names to actual functions. This could be done by providing an auto-generated file of function names and their data types and such, and generating code based on that. It's a little bit of work, but doable. Perhaps we can even have Perl and such use that listing to generate scripting bindings. Food for thought. The main question is, when will this be done? Everyone's busy, and I don't know if the other developers even have an interest. So, it'll be me. I have a bit of time off during December that I hope to use for Gaim loving time. I've done the D-BUS stuff for other projects, so I'm quite familiar with it anyway. I'll see what I can do this month and next. > My question is .. >=20 > Where is the current 'idea', the 'concept' of GAIM heading? Are the core > GAIM developers interested in this type of integration and cooperation > with other applications? And if so, what is the status? I can't speak for others, but I am. > I saw, for example, that you need to utilise a gaim-remote commandline > tool to make Gaim do some common operations from within another > application. My first thought was: "how can that still be true these > days?" and "but...there's CORBA and ORBit, no?!" It even looks like it's > using manual sockets-code (much like how xmms has remoting?). Wtf? See D-BUS above. Christian =20 --=20 Christian Hammond <> The Galago Project ch...@gn... <> http://galago.sourceforge.net/ "During my service in the United States Congress, I took the initiative in creating the Internet." -- Al Gore, March 9, 1999 |
From: Philip V. H. <spa...@fr...> - 2004-11-20 13:27:25
|
On Fri, 2004-11-19 at 09:41 -0800, Christian Hammond wrote: [CUT] > As others have said, we've had other things that we've had to do. Part > of the problem is that outside of Gaim, we're all really busy. I > personally am getting off work around 8 or 9 at night lately. Okay :-), which is a common something for all developers of opensource products. What I'm trying to achieve here, however, isn't to get developer-time from specifically the Gaim developers. I'm rather trying to bring the concept, the idea of "desktop integration", to the minds of the various Gaim core developers. I'm not trying to say, of course, they have to agree with me. Today, I feel the need for a more tight integration with those other applications. Gaim, being the #1 application used for the purpose of Instant Messaging and buddy-availability checking on the GNOME Desktop, could fulfill a very important role. I am not saying that it should. I am, however, hoping someday it will. It would create a lot very nice possibilities for many GNOME applications. I do understand many Gaim users don't feel connected in any way with the GNOME Desktop nor the applications mentioned. Therefor should this desktop integration be implemented in a way that all supported desktop-platforms can use it (freedesktop.org-style). The exact same integration could then also happen on a desktop like KDE. Your Galago project is one of the very few but nice projects that might make this happen. Chances are high that I will be investigating (and eventually helping) such projects. I repeat I'm willing to help any serious, teamed, and mind-synchronized effort going towards desktop integration. Building desktop integration is something, much like agreeing on a Human Interface Guideline, that needs the love and minds of most application developers. Not just one individual. > > My opinion is of course that such an integration is a good thing. > Definitely. I am glad we agree on this :) [CUT] > > It would, for example, be nice if evolution could query GAIM about the > > presence of an individual: http://www.gnome.org/bounties/IM.html#127546. > > on http://bugzilla.gnome.org/show_bug.cgi?id=127546 you can find a > > proposed implementation of such a featurerequest. > This is going to happen through Galago. I have some partial Evolution > code for this, but it's going to be redone to use their EPlugin API. I've recently did some very small EPlugin (exporting calendars as a comma separated file in the save-calendar plugin) and decided that I will probably learn myself using that API. So I might be interested in helping out (my holiday will start in a few weeks). > The current implementation offered on there that I think you're seeing > is actually far more complicated than it needs to be. One way or > another, it's going to use Galago. The developer of one of those > patches is just waiting for a Galago release and some API changes. > However, it's still overkill, as he's using his own custom framework > and widgets that Galago already provides. Okay > I would like Galago to eventually be tied in directly to Gaim. Of > course, this would be iff Gaim has been compiled with D-BUS support > (more on this in a minute) and when Galago reaches a stability point > where I'd feel comfortable doing this. Okay > Second best solution would be to bundle the Gaim-Galago plugin with > Gaim directly. If this happens, it'll be after Gaim 2.0 stable, as the > Gaim-Galago plugin will need some changes for the new status API. Okay. I am not seeing all this happening in a short time frame ;-) > Now, for D-BUS.. > > D-BUS is going to be a standard thing on all distros very soon. It's > needed for HAL, it'll be needed for GNOME, and a lot of other apps are > moving to it. Yes. I should really be checking it out sooner or later (I haven't had the time this year). > The downside is, it doesn't work on Windows and some other operating > systems. However, if it doesn't work there, it won't exist there, and > we'll just handle it through configure checks and #ifdefs, like we > always do. > Once we have D-BUS support built-in, a lot of things that are > currently plugins could then be services. Gaim-Galago could just be > some thing listening in a separate process for Gaim D-BUS events. Sounds like a good idea > Integrating this would take a bit of work. The easiest way to go about > it would be creating a translation layer for signals and API > functions. > > The signals part is easy. We tie into a function, much like loader > plugins do, and we get every signal. Then we rebroadcast them. > API functions are harder. We would need a way to map the function > names to actual functions. This could be done by providing an > auto-generated file of function names and their data types and such, > and generating code based on that. It's a little bit of work, but > doable. Perhaps we can even have Perl and such use that listing to > generate scripting bindings. Food for thought. > > The main question is, when will this be done? Everyone's busy, and I > don't know if the other developers even have an interest. So, it'll be > me. I have a bit of time off during December that I hope to use for > Gaim loving time. I've done the D-BUS stuff for other projects, so I'm > quite familiar with it anyway. I'll see what I can do this month and > next. Okay. I don't think time is already very important. Building this fancy thing called "desktop integration" is not something thats going to happen over one night. The important thing, however, is people like you who are willing to make it happen. > > My question is .. > > > > Where is the current 'idea', the 'concept' of GAIM heading? Are the core > > GAIM developers interested in this type of integration and cooperation > > with other applications? And if so, what is the status? > > I can't speak for others, but I am. Thats good to know. > > I saw, for example, that you need to utilise a gaim-remote commandline > > tool to make Gaim do some common operations from within another > > application. My first thought was: "how can that still be true these > > days?" and "but...there's CORBA and ORBit, no?!" It even looks like it's > > using manual sockets-code (much like how xmms has remoting?). Wtf? > > See D-BUS above. -- Philip Van Hoof, Software Developer @ Cronos home: me at freax dot org gnome: pvanhoof at gnome dot org work: philip dot vanhoof at cronos dot be junk: philip dot vanhoof at gmail dot com http://www.freax.be, http://www.freax.eu.org |
From: Mark D. <ma...@ki...> - 2004-11-20 18:43:21
|
On Sat, 20 Nov 2004 14:27:15 +0100, Philip Van Hoof wrote > Okay. I don't think time is already very important. Building this fancy > thing called "desktop integration" is not something thats going to > happen over one night. The important thing, however, is people like you > who are willing to make it happen. Could you give some specific examples of the kinds of desktop integration you would like to see in Gaim? -Mark -- O O Mark Doliner \ | ma...@ki... \ | www.kingant.net "There needs to be a better word for weird." |
From: Philip V. H. <spa...@fr...> - 2004-11-21 15:30:24
|
On Sat, 2004-11-20 at 13:43 -0500, Mark Doliner wrote: > On Sat, 20 Nov 2004 14:27:15 +0100, Philip Van Hoof wrote > > Okay. I don't think time is already very important. Building this fancy > > thing called "desktop integration" is not something thats going to > > happen over one night. The important thing, however, is people like you > > who are willing to make it happen. > > Could you give some specific examples of the kinds of desktop integration you > would like to see in Gaim? Because last person only talked about integration with filesharing applications (which is not really the first thing that comes into my mind when I talk about desktop integration), I'll post some examples. o. Linkage of your Buddy records with the contactlist records o. Automatically retrieve/update and offer public information that can go into the contactlist o. Presence notification in Evolution. When sending an E-mail to one of your available/online buddies, you will see his IM icon which sais something about his status in the upperright corner of the E-mail composer window. When reading an E-mail, same thing. When reading/managing tasks, calendars and contactlist-records you see this IM icon. http://bugzilla.gnome.org/show_bug.cgi?id=127546 o. Linkage with Tasks and meetings (the calendar) o. Show in Gaim what tasks and meetings are related to the person whom you are chatting with. Look at the Clock-applet of a recent GNOME Desktop. The relation between Time and calendar-items has already been integrated with eachother. The other entities of a task/meeting are it's attendees. Those attendees will probably also sit in the buddy-list of Gaim. So we can do integration. o. Tight integration with gnomemeeting o. Show the video-conferencing capabilities of a available user (can you call the user?, does he have video-conferencing software?) o. Where the user-icon in a IM/chat-window gets placed now could come a videostream if available and wanted at that time by both users. o. Integration with Evolution meetings, gnomemeeting and Gaim o. Evolution could at the start of a meeting automatically create a Jabber-channel and could (if so desired per attendee) automatically make the attendees join that channel by launching/user Gaim's features. Once all attendees are ready, a videoconferencing meeting could automatically start. o. Of course, if no videoconferencing is desired, make it easy to schedule "instant messaging"-only meetings. o. Integration with E-mail in general o. Make it (very) easy to attach an IM-log to an E-mail -- Philip Van Hoof, Software Developer @ Cronos home: me at freax dot org gnome: pvanhoof at gnome dot org work: philip dot vanhoof at cronos dot be junk: philip dot vanhoof at gmail dot com http://www.freax.be, http://www.freax.eu.org |
From: Mark D. <ma...@ki...> - 2004-11-21 18:31:45
|
On Sun, 21 Nov 2004 15:14:15 +0100, Philip Van Hoof wrote > o. Linkage with Tasks and meetings (the calendar) > o. Show in Gaim what tasks and meetings are related to the > person whom you are chatting with. Look at the Clock-applet > of a recent GNOME Desktop. The relation between Time and > calendar-items has already been integrated with eachother. > The other entities of a task/meeting are it's attendees. > Those attendees will probably also sit in the buddy-list of > Gaim. So we can do integration. I like the idea of having Gaim be an IM client, and only support the things that the official IM programs support. For this suggestion, I really like the approach taken by Nat Friedman's dashboard (http://www.nat.org/dashboard/). I'm not against any of the things you mentioned, but I don't think you're going to get much help from too many people... Like Chip said, the core developers are all pretty busy, and I think most of us would rather spend our time on things we consider a higher priority (like finishing the status re-write). But really, you don't NEED a group of people to do any of these things... just one person with a lot of time. -Mark -- O O Mark Doliner \ | ma...@ki... \ | www.kingant.net "There needs to be a better word for weird." |
From: Philip V. H. <spa...@fr...> - 2004-11-22 12:41:00
|
On Sun, 2004-11-21 at 13:30 -0500, Mark Doliner wrote: > On Sun, 21 Nov 2004 15:14:15 +0100, Philip Van Hoof wrote > > o. Linkage with Tasks and meetings (the calendar) > > o. Show in Gaim what tasks and meetings are related to the > > person whom you are chatting with. Look at the Clock-applet > > of a recent GNOME Desktop. The relation between Time and > > calendar-items has already been integrated with eachother. > > The other entities of a task/meeting are it's attendees. > > Those attendees will probably also sit in the buddy-list of > > Gaim. So we can do integration. > > I like the idea of having Gaim be an IM client, and only support the > things that the official IM programs support. Okay, but don't misunderstand me here. I am not proposing to add functionality to the software. The functional boundaries of each software must be indeed limited to a predefined scope. o. For Gaim this is probably everything thats related to Instant Messaging. o. For Evolution this is everything thats related to groupware o. And for gnomemeeting it's everything related to videoconferencing It sounds stupid to add groupware functionality to gaim, indeed. But it doesn't sound stupid (to me) to integrate gaim with Evolution to allow people to combine their groupware tasks with their instant messaging. What I am proposing is to allow other application to integrate with Gaim and to integrate Gaim with other applications in such a way that no functionality is lost for users who dislike using those other applications. > For this suggestion, I really like the approach taken by Nat > Friedman's dashboard (http://www.nat.org/dashboard/). > I'm not against any of the things you mentioned, but I don't think > you're going to get much help from too many people... Like Chip said, > the core developers are all pretty busy, and I think most of us would > rather spend our time on things we consider a higher priority (like > finishing the status re-write). But really, you don't NEED a group of > people to do any of these things... just one person with a lot of > time. Not just one person. This needs a small group of people and the acceptance of the other people involved with the development of the affected components. It will bring important changes to Gaim. It will probably not be "just a small plugin". My opinion is that a signal from the gaim developers showing this acceptance, would probably make developers (of other applications) interested in doing work on integration with gaim. Me, myself, included. ps. One person replied me in private about his attempts to get such integration-technologies in gaim, while at first I didn't expect any positive reaction. -- Philip Van Hoof, Software Developer @ Cronos home: me at freax dot org gnome: pvanhoof at gnome dot org work: philip dot vanhoof at cronos dot be junk: philip dot vanhoof at gmail dot com http://www.freax.be, http://www.freax.eu.org |